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ABSTRACT 

System(s)-of-Systems  (SoS)  is  broadly  acknowledged  as  an  engineering  challenge  for 
defence  organisations,  due  to  high  complexity  of  various  military  SoS  and  their 
development  processes.  Inadequate  understanding  of  SoS  problems  and  inability  to 
manage  complexity  encountered  in  planning,  development  and  operation  of  multiple 
interdependent  SoS  can  undermine  not  only  performance  and  effectiveness  of 
engineering  practice  and  development  activities,  but  also  quality  of  their  products  and 
outcomes.  This  report  introduces  a  systems  thinking-based  approach,  SoS  thinking, 
which  offers  a  language  and  a  thoughtful  process  to  conceptualise,  understand, 
communicate  about  and  assess  military  SoS.  Based  on  the  multidimensional  thinking, 
high  complexity  of  SoS  problems  can  be  explored  and  addressed  through  using  a  set  of 
SoS  lenses  in  a  number  of  important  aspects,  including  the  problem  space,  diversity, 
interdependencies,  design  paradigm,  development  states  and  technical  statuses.  SoS 
thinking  provides  a  foundation  for  further  developments  of  adequate  methods,  metrics 
and  solutions  for  SoS  engineering  practice. 
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A  Systems  Thinking  Approach  to  Engineering  Challenges  of 

Military  Systems-of-Systems 

Executive  Summary 


System(s)-of-Systems  (SoS)  is  broadly  acknowledged  as  an  engineering  and  management 
challenge  for  defence  organisations,  in  particular  in  pursuing  joint  force  integration  and  in 
delivering  effective  future  networked  force  capabilities.  Military  SoS  vary  across  Defence, 
ranging  across  information-based  SoS,  platform-based  SoS,  capability-based  SoS,  and 
operation-based  SoS.  The  ubiquity  of  military  SoS  is  a  reality  facing  planning,  analysis, 
development  and  operation  of  modern  defence  force  and  capabilities.  Inadequate 
understanding  of  SoS  problems  and  inability  to  effectively  manage  the  complexity  of 
multiple  interdependent  SoS  can  undermine  performance  and  effectiveness  of 
architectural  approaches,  systems  engineering  practice  and  development  activities.  This 
also  results  in  problems  and  quality  issues  of  products  and  outcomes  generated  in  force 
design  and  integrated  capability  development.  The  high  complexity  of  military  SoS 
directly  contributes  to  major  cost  and  schedule  overruns  in  development,  acquisition  and 
operation  of  integrated  systems  and  capabilities. 

In  many  areas  within  Defence,  there  is  often  a  collection  of  interdependent  human-cyber- 
physical  systems  to  be  dealt  with.  Realising  the  required  levels  of  integration  and 
interoperability  for  such  a  collection  of  systems  in  an  often  evolving  technical  and 
operational  context  can  become  messy  if  their  interdependencies  and  interrelationships  are 
not  properly  specified,  engineered,  and  managed.  Dealing  with  a  messy  collection  of 
systems  with  no  adequate  conceptualisation  and  contextualisation  is  a  failure  of 
engineering  and  management  that  an  organisation  should  avoid.  The  applications  of 
traditional  systems  engineering  practice  and  architectural  approaches  may  become 
problematic  or  even  fail  if  they  are  applied  to  such  a  messy  collection  of  systems. 

Understanding  the  difference  between  a  single  SoS  and  a  SoS  problem  space  where  there 
are  multiple  interdependent  and  interrelated  SoS  is  important.  An  inability  to  effectively 
conceptualise  the  SoS  problem  space  or  meaningfully  and  manageably  identifying  the  SoS 
is  one  of  the  underlying  causes  resulting  in  major  problems  in  undertaking  engineering 
activities  and  developing  architectures  involving  multiple  SoS. 

The  challenge  of  designing  and  delivering  SoSs  is  a  reality  facing  the  whole  Defence.  It 
requires  clear  guidance  and  a  commonly  agreed  approach  that  can  enable  key 
stakeholders  and  professionals  to  systematically  design  adequate  processes  for  joint  force 
integration  and  capability  development,  and  consistently  deal  with  SoS  challenges. 

The  SoS  thinking  approach  proposed  in  this  report  is  an  extension  of  systems  thinking, 
specifically  introduced  as  an  enabler  for  tackling  SoS  problems.  It  offers  a  language  and  an 
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approach  to  conceptualise,  understand,  communicate  about  and  assess  military  SoS.  It 
offers  an  approach  to  address  the  high  complexity  of  SoS  problems  so  that  they  can  be 
contextualised,  explored  and  addressed  through  using  a  set  of  SoS  lenses  in  a  number  of 
important  perspectives,  including: 

•  awareness  of  a  SoS  problem  space  with  its  engineering  factors 

•  SoS  categorisation  and  identification 

•  SoS  interdependencies 

•  SoS  development  states 

•  SoS  technical  statuses 

•  SoS  design  relevance  and  paradigm 

•  extended  SoS  community  of  practice. 

SoS  thinking  offers  a  strategy  and  approach  to  establishing  a  systematic  understanding  of 
SoS,  which,  based  on  a  set  of  SoS  concepts  associated  with  those  perspectives,  can  be  used 
to  address  SoS  engineering  challenges.  SoS  thinking  can  be  applied  as  a  7-step-based 
process  to  help  SoS  activities  (from  planning,  analysis,  design,  development,  integration, 
assessment,  management  to  operation)  and  engineering  practice.  In  particular,  it  enables 
practitioners  to  effectively  conceptualise  and  manage  a  SoS  problem  space  and  avoid 
dealing  with  a  messy  collection  of  systems  or  SoS. 

SoS  thinking  has  the  potential  to  help  review  and  examine  various  problems  and  issues 
encountered  in  architecture  and  engineering  practice.  It  can  also  provide  a  shared 
foundation  for  further  developments  of  adequate  methods,  metrics,  solutions  and  tools  for 
SoS  engineering  practice.  Further  applications  of  SoS  thinking  can  help  address  a  number 
of  important  issues  or  tasks  of  military  SoS  development  and  management  in  a  joint 
manner  or  through  using  a  shared  thinking  strategy  and  approach,  including: 

•  categorisation-based  SoS  design  (or  architecture)  requirement  specifications 

•  development  state-based  SoS  development  control  and  management 

•  SoS  thinking-based  mission  space  (scenarios)  and  capability  design  management 

•  SoS  identification  and  relationship-based  SoS  engineering  artefacts  management 

•  SoS  identification  and  relationship-based  SoS  integration  management  and 
assessment 

•  SoS  deign  and  technical  status  assessment  and  management 

•  SoS  identification  and  relationship-based  SoS  lifecycle  management. 

This  research  proposes  a  new  thinking  strategy  and  innovative  approach  of  systems 
thinking  specifically  to  SoS  problems.  SoS  thinking  introduces  new  concepts,  metrics, 
methods  and  a  language  to  the  research  and  practice  of  systems  engineering  for  SoS.  In 
particular,  it  helps  development  activities  achieve  conceptualisation  with  theory,  shared 
understanding,  and  consistent  contextualisation  in  a  SoS  problem  space.  SoS  Thinking 
provides  approaches  and  potential  solutions  to  facilitate  Defence  in  addressing  SoS 
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engineering  challenges  in  joint  force  design  and  integration  to  develop  integrated 
capabilities. 

The  challenge  of  military  SoS  requires  an  enhancement  of  professional  skills  in  many  areas 
in  Defence  to  effectively  understand  and  deal  with  various  military  SoS.  SoS  thinking  is 
specifically  developed  to  help  defence  stakeholders  and  professionals  understand  and 
communicate  SoS  problems  they  face.  The  application  of  SoS  thinking  can  potentially 
enhance  force  design  and  bring  significant  benefits  to  engineering  practices  required  for 
planning,  development  and  management  of  joint  force  integration  and  integrated 
capabilities.  It  also  has  the  potential  to  enhance  warfighters'  understanding  of  the  SoS  they 
are  using  and  improve  their  confidence  in  management  and  operation  of  SoS-based  joint 
force  and  integrated  capabilities. 

The  following  recommendations  are  made  in  this  report: 

•  Defence  needs  clear  and  authoritative  guidance  on  effective  use  of  the  term,  SoS, 
as  part  of  relevant  development  or  process  guidance,  in  order  to  effectively 
address  SoS  challenges  and  get  real  benefits  from  relevant  disciplines; 

•  Defence  needs  the  best  practice  and  innovative  approaches  in  conceptualisation 
and  contextualisation  for  its  military  SoS  problems; 

•  Defence  should  establish  the  lifecycle  management  concept  for  military  SoS  in 
different  categories,  in  order  to  achieve  objectives  and  outcomes  of  force  design 
and  joint  force  integration  with  required  interoperability; 

•  Defence  should  establish  accountability  management  against  military  SoS  in 
different  categories  for  key  stakeholders  in  different  areas; 

•  Defence  needs  to  develop  and  use  adequate  methods,  solutions  and  tools  for 
practices  of  SoS  thinking  and  SoS  engineering  (SoSE);  and 

•  Defence  should  develop  adequate  training  courses  on  SoS  thinking  and  SoSE. 


UNCLASSIFIED 


UNCLASSIFIED 


Authors 


Dr  Pin  Chen 

Joint  &  Operations  Analysis  Division 

Dr  Pin  Chen  is  a  Senior  Scientist  with  the  Joint  &  Operations 
Analysis  Division  (JO AD)  of  DST  Group,  the  chief  investigator  for 
SoS  Thinking  study  and  previously  led  research  tasks  in  architecture 
practice  study  for  Defence,  Systems  Engineering  for  System-of- 
Systems  (SoS),  defence  architecture  information  model  development 
and  multiple  unmanned  systems  cooperation  for  mission  systems.  His 
current  research  interests  are  focused  on  a  number  of  areas,  including 
SoS  Thinking,  SoS  engineering  practice,  complex  systems  design, 
force-level  modelling  and  design,  complexity  management,  force  and 
capability  integration,  analysis  and  evaluation  of  integrated  force  and 
capabilities. 


Dr  Mark  Unewisse 

Joint  &  Operations  Analysis  Division 


Dr  Mark  Unewisse  leads  the  Defence  Systems  Integration  program 
within  DST  Group's  Joint  and  Operations  Analysis  Division.  He 
holds  degrees  in  Physics,  Electrical  Engineering  and  a  PhD  from 
UNSW.  Mark's  32  year  career  with  Defence  has  spanned  S&T  support 
to:  submarine  and  surface  ship  simulation,  infrared  systems;  military 
experimentation;  combat  training  centres;  Army  aviation;  Land  and 
Joint  Fires;  Land  C2  and  NCW;  Combat  Vehicle  Systems;  force 
protection,  and  supporting  the  RAAF  Combat  Support  Group;  Land 
ISTAR,  and  system-of-systems/force-level  integration.  He  has  also 
undertaken  a  range  of  corporate  roles  within  DST.  Mark's  current 
research  is  focused  joint  force  integration  and  SoS  engineering. 


UNCLASSIFIED 


UNCLASSIFIED 

DST-Group-TR-3271 

Contents 

1.  INTRODUCTION . 1 

2.  SOS  ENGINEERING  OVERVIEW . 2 

3.  SOS  THINKING . 4 

4.  MILITARY  SOS  PROBLEM  SPACES  AND  ENGINEERING  FACTORS . 7 

5.  SOS  CATEGORISATION  AND  IDENTIFICATION . 10 

6.  SOS  INTERDEPENDENCIES . 16 

7.  SOS  DEVELOPMENT  STATES  AND  TRANSITION  PATHS . 21 

8.  SOS  TECHNICAL  STATUSES . 26 

9.  SOS  DESIGN  RELEVANCE  AND  PARADIGM . 28 

10.  EXTENDED  COMMUNITY  OF  PRACTICE  (COP)  FOR  SOSE  AND  SOS 

ACTIVITIES . 33 

11.  SOS  THINKING  APPROACH . 35 

12.  APPLICATIONS  OF  SOS  THINKING . 38 

13.  FURTHER  STUDIES  AND  RECOMMENDATIONS . 41 

14.  CONCLUSIONS . 42 

REFERENCES . 43 


UNCLASSIFIED 


UNCLASSIFIED 

DST-Group-TR-3271 


Glossary 

AOC 

Air  Operation  Centre 

BMDS 

Ballistic  Missile  Defence  System 

BMS 

Battlespace  Management  systems 

C2 

Command  and  Control 

C4ISR 

Command,  Control,  Computer  and  Communications  Intelligence 
Surveillance  and  Recognisance 

CASG 

Capability  and  Sustainment  Group  (formerly  DMO) 

CDG 

Capability  Development  Group 

CLC 

Capability  Life  Cycle 

CMS 

Combat  Management  System 

CONOPS 

Concepts  of  Operation 

CoP 

Community  of  Practice 

CIOG 

Chief  Information  Officer  Group 

C_SoS 

Capability-based  SoS 

DIE 

Defence  Information  Environment 

DMO 

Defence  Materiel  Organisation  (now  CASG) 

DoD 

Department  of  Defence  (US) 

DST  Group 

ESE 

Defence  Science  &  Technology  Group 

Enterprise  Systems  Engineering 

FCS 

Future  Combat  System 

IOCD 

Integrating  Operational  Concept  Document 

IN 

Integration  Needs 

INCOSE 

International  Council  of  Systems  Engineering 

IER 

Information  Exchange  Requirements 

ISR 

Intelligence  Surveillance  and  Recognisance 

JSF 

I_SoS 

Joint  Strike  Fighter 

Information-based  SoS 

LHD 

Landing  Helicopter  Dock  (Amphibious  Assault  Ship) 

LISI 

Levels  of  Information  Systems  Interoperability 

MCM 

Mine  Counter-Measures 

MOE 

Measures  of  Effectiveness 

UNCLASSIFIED 


UNCLASSIFIED 


DST-Group-TR-3271 


MOP 

Measures  of  Performance 

M_SoS 

Mission-based  SoS 

NCO 

Network  Centric  Operation 

OR 

Operations  Research 

0_SoS 

Operation-based  SoS 

P_SoS 

Platform-based  SoS 

SCOTS 

SoS  Characterisation  of  Operation  and  Technical  Status 

SE 

Systems  Engineering 

SoS 

System(s)-of-systems 

SoSE 

SoS  Engineering 

T&E 

Test  and  Evaluation 

TBS 

Theatre  Broadcast  System 

TRA 

Technical  Risk  Assessment 

U_SoS 

Unit  (force)-based  SoS 

VCDF 

Vice  Chief  Defence  Force 

V&V 

Verification  and  Validation 

UNCLASSIFIED 


DST-Group-TR-3271 


UNCLASSIFIED 


This  page  is  intentionally  blank 


UNCLASSIFIED 


UNCLASSIFIED 


DST-Group-TR-3271 


1.  Introduction 


The  conceptualisation,  design  and  implementation  of  system(s)-of-systems  (SoS)  is  broadly 
acknowledged  as  a  significant  engineering  challenge  due  to  its  high  complexity  in  multiple 
aspects.  SoS  engineering  challenges  differ  from  developing  a  single  large  complex  system. 
For  many  large  organisations,  in  particular  defence  organisations,  this  challenge 
encompasses  how  to  effectively  integrate,  manage,  evolve  and  operate  multiple 
heterogeneous  systems  and  capabilities.  Defence's  human-cyber-physical  systems  need  to 
be  deployed  in  a  range  of  joint  operations  with  integrated  capabilities  in  various  forms  of 
SoS.  Due  to  the  multitude  of  interdependencies  and  high  integration  requirements, 
military  systems,  capabilities  and  force  elements  and  their  integration  form  a  SoS  problem 
space  where  there  may  be  multiple  SoS.  This  SoS  problem  space  will  become  messy  if  the 
interdependencies  and  interrelationships  are  not  systematically  defined  and  adequately 
managed.  The  high  complexity  of  military  SoS  can  significantly  contribute  to  dramatic 
increases  of  costs  and  schedule  overruns  in  development,  acquisition  and  operation  of 
integrated  systems  and  capabilities. 

The  INCOSE  Systems  Engineering  Handbook  describes  SoS  as  "systems-of -interest  whose 
systems  element  are  themselves  systems;  typically,  these  entail  large-scale  inter¬ 
disciplinary  problems  involving  multiple,  heterogeneous,  distributed  systems.  These 
interoperating  collections  of  component  systems  usually  produce  results  unachievable  by 
the  individual  system  alone."  [INCOSE,  2015] 

Military  SoS  challenges  are  experienced  in  many  important  areas  or  activities.  Defence 
needs  to  envisage,  plan,  develop,  generate  and  operate  a  variety  of  interrelated  force 
elements,  systems  and  capabilities  across  multiple  contexts  in  a  complicated  SoS  problem 
space.  These  SoS  are  often  in  different  development  states  or  stages  of  their  life-cycles  and 
need  to  evolve.  Processes  of  planning,  design,  development,  management  and  operation 
become  difficult  or  challenging  tasks,  due  to  high  complexity  of  both  military  systems  and 
development  activities. 

To  date,  the  effectiveness  of  the  current  engineering  and  architectural  approaches  used  for 
military  systems  and  SoS  has  proved  to  be  less  than  ideal.  Viewed  from  a  'soft  systems' 
perspective,  this  is  mainly  due  to  an  inability  to  correctly  understand  and  effectively  cope 
with  high  complexity  of  military  SoS.  One  of  main  issues  commonly  facing  existing  SoS 
concepts,  engineering  practice  and  architectural  approaches  is  how  to  meaningfully  and 
consistently  identify  SoS  with  manageability  or  effectively  conceptualise  a  SoS  problem 
space,  in  order  to  avoid  dealing  with  a  messy  collection  of  systems  or  SoS. 

This  report  introduces  a  SoS  thinking  approach  to  underpin  understanding,  development 
and  management  of  military  SoS.  It  employs  soft  systems  philosophies  and  principles  to 
establish  a  foundation  specifically  for  the  development  of  SoS  concepts,  solutions, 
methods,  metrics  and  tools.  In  particular,  through  offering  a  language  and  a  set  of 
complexity  lenses,  SoS  thinking  seeks  to  clarify  in  a  SoS  problem  space: 

•  what  potential  categories  of  SoS  should  be  considered  in  military  domains; 
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•  what  relationships  or  interdependencies  between  SoS  exist  and  should  be  modelled 
and  addressed  in  architecture  and  integration  and  how; 

•  what  development  states  they  are  in  and  will  go  through; 

•  what  technical  statuses  they  could  end  up  with  and  why;  and 

•  how  different  SoS  could  be  in  operation  if  they  are  designed  and  developed 
differently. 

A  7-step-based  SoS  thinking  approach  is  proposed  to  help  researchers  and  practitioners 
conceptualise  a  SoS  problem  space  with  theory,  establish  a  holistic  and  shared 
understanding  of  SoS  involved  and  their  situations  of  development  states  and  technical 
statuses,  and  capture  and  manage  important  engineering  artefacts. 

The  main  contributions  from  this  research  are  in  two  folds.  To  the  literature,  first,  it 
proposes  a  new  thinking  strategy  and  an  innovative  approach  of  systems  thinking 
specifically  to  SoS  problems.  SoS  thinking  introduces  new  concepts,  metrics,  methods  and 
a  language  to  the  research  and  practice  of  systems  engineering  for  SoS.  In  particular,  it 
helps  development  activities  achieve  conceptualisation  with  theory,  shared 
understanding,  and  characterisation  of  engineering  influence  and  outcomes  for  multiple 
and  related  SoS  in  a  SoS  problem  space.  Secondly,  it  provides  approaches  and  potential 
solutions  to  facilitate  Defence  in  addressing  SoS  engineering  challenges  in  joint  force 
design  and  integration  to  develop  integrated  capabilities. 


2.  SoS  Engineering  Overview 

The  efforts  made  by  Systems  Engineering  (SE)  community  to  address  many  engineering 
issues  and  difficulties  caused  by  the  concept  of  SoS  started  two  decades  ago.  Maier  [1996] 
discussed  architecting  principles  for  SoS.  Levis  [2000]  explored  the  relations  between  SE 
process  and  applications  of  US  DoD  C4ISR  Architecture  Framework.  Cook's  effort  [2001] 
was  to  further  investigate  features  of  SoS  and  innovative  SE  methods  based  on  Systems 
Thinking.  Combining  architecture  frameworks  (such  as  C4ISR  Architecture  Framework)  or 
enterprise  architecture  initiatives  (for  example,  TAGOF  or  Zachman  framework)  with  IT 
strategic  planning,  Carlock  [2001]  presented  the  Enterprise  Systems  Engineering  (ESE)  as  a 
SoS  engineering  solution  to  engineer  whole  business  and  systems  as  a  whole  for 
information-intensive  organisations.  Based  on  Handy's  principles  of  a  'new-federalism'. 
Sage  [2001]  first  recommended  a  canonical  approach  to  engineering  and  management  of 
SoS  that  combines  federated  SE  principles  with  evolutionary  acquisition  life  cycles.  By 
suggesting  the  expansion  of  traditional  SE  process  that  is  often  a  project-based  or  is 
targeted  to  deliver  a  single  final  product,  many  SoS  SE  studies  are  intended  to  provide 
better  solutions  for  the  task  of  'developing  a  SoS'.  High  engineering  complexity  in 
development  and  management  of  SoS  discussed  in  [Sage,  2001;  Carlock,  2001]  shows  great 
challenges  for  SE  practitioners  to  effectively  organise  SE  processes  and  activities  in 
evolutionary  development  of  SoS  and  also  indicates  a  need  of  considering  different  SE 
strategies  at  a  level  above  individual  projects. 
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SoS  Engineering  (SoSE)  practice  is  an  emerging  discipline  and  has  been  proposed  or 
conducted  with  different  foci  using  different  methods  and  processes,  after  a  decade  long 
journey  of  development.  Keating's  team  has  continuously  worked  on  theory  and  design  of 
SoSE  methodologies  [Keating,  2003,  2010,  2011]  since  2003.  Chen  and  Clothier  [Chen,  2003] 
explored  philosophical  and  methodological  difference  between  SE  and  SoSE,  that  is, 
'developing  a  system  (or  SoS)'  and  'developing  systems  in  a  context  of  a  SoS  environment'; 
and  suggested  a  focus  shifting  from  systems  development  to  systematic  SoS  evolution 
management  enabled  by  systematic  architecture  management  at  an  enterprise  level.  SoS 
management  study  [Sauser,  2008]  reveals  and  explores  the  SoS  philosophy  and  paradox  in 
SoS  engineering  and  management.  After  publishing  the  US  DoD  SE  guide  for  SoS  [DoD, 

2007] ,  Dahmann  and  her  colleagues  continued  their  efforts  in  defining  SoS  processes  and 
models  as  shown  in  Figure  1,  and  studying  challenges  and  requirements  of  artefacts 
management  for  SoSE  [Dahmann,  2008,  2010,  2011].  Understandings  of  SoSE  requirements 
continued  to  be  improved  by  Gorod's  efforts  on  SoSE  management  framework  [Gorod, 

2008] , 
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Figure  1  A  SoS  analysis  and  engineering  -paradigm  quoted  from  Dahmann' s  zvork  (2008) 

Despite  the  various  efforts  made  in  the  methodology  development,  as  shown  in  the  Pain 
Points  Survey  conducted  by  INCOSE  SoS  Working  group  in  2011  [Dahmann,  2014],  SoSE 
remains  a  challenging  task  for  practitioners.  This  situation  is  not  a  surprise  because  SoSE 
itself  is  often  not  clearly  presented  when  applied  to  the  problem  space  of  military  SoS. 
SoSE  as  a  discipline  is  still  in  its  embryonic  stages  of  development  [Keating,  2011]  without 
clear  definitions  in  its  scopes,  tasks,  processes  and  objectives,  and  with  confusion  in  the 
SoS  identification,  nature,  operation  characteristics,  boundaries,  relationships  and 
evolution  or  lifecycles. 

Many  existing  concepts  and  principles  of  SoS  are  mainly  based  on  the  consideration  of  a 
single  SoS  (evident  by  the  definition  of  SoS,  Maier's  architecting  principles  and  Adams' 
systems  principles  [Adams,  2011]).  They  are  however  not  sufficient  or  applicable  to  a 
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situation  where  either  there  are  many  interdependent  systems  or  multiple  inter-related 
SoS  co-exist  in  a  SoS  problem  space.  The  SoS  analysis  and  engineering  paradigm  become 
extremely  complicated  in  practice  for  the  whole  SoS  problem  space.  From  the  viewpoints 
of  both  manageability  and  the  satisfaction  to  the  definitions  of  SoS,  it  is  a  problematic 
exercise  of  conceptualisation  to  consider  such  a  collection  of  multiple  SoS  as  a  'big'  or 
'super'  SoS.  It  is  also  methodologically  not  encouraged  when  applying  some  engineering 
or  architectural  approaches. 

Inadequate  or  inconsistent  identification  or  conceptualisation  of  SoS  (including  no 
identification  of  SoS,  no  matter  whether  actually  using  the  term,  SoS)  is  one  of  the  main 
causes  of  problematic  development  of  architectures  and  failures  of  engineering  practice 
involving  multiple  SoS.  It  is  because  of  these  problems  that  both  SoS  concept  and  SoS 
Engineering  have  not  been  widely  considered  and  accepted  by  the  defence  community. 
However,  this  SoS  reality  is  facing  the  whole  Defence,  which  cannot  be  avoided  by  simply 
not  using  the  term,  SoS. 

Engineering  efforts  or  factors,  from  planning  decisions,  design  products,  engineering 
practice  to  development  outcomes,  jointly  have  great  impact  on  SoS.  There  is,  however,  no 
standard  SoSE  practice  since  the  current  SoSE  practice  is  often  considered  and  undertaken 
in  ad  hoc  manners  with  different  levels  of  efforts.  It  is  applied  in  various  SoS  activities, 
from  planning,  analysis,  development,  evaluation,  integration  to  acquisition,  with 
different  focuses  for  very  different  problems  of  SoS.  Such  a  practice  across  the  organisation 
makes  SoS  activities,  including  traditional  SE  practice  applied  in  acquisition,  ineffective 
and  inefficient,  or  inconsistent.  Development  of  models  or  architectural  views,  for 
example,  is  only  one  of  main  activities  of  SoSE,  which  need  to  be  orchestrated  with  other 
activities  and  produce  coherent  outcomes.  Otherwise,  models  and  architectures  generated 
will  be  flawed  and  have  limited  values  if  SoS  are  not  understood  adequately  and  properly 
handled  at  their  inception. 

There  are  certain  common  challenges  for  all  SoS  activities,  which  have  direct  impact  on 
effectiveness  of  SoS  activities  and  SoSE  practice.  They  include:  1)  high  complexity  and  a 
variety  of  SoS,  and  their  different  features  and  requirements  in  formation  and 
development;  2)  interdependencies  or  relationships  between  various  SoS;  3) 
architecture/ model  management;  4)  lifecycle  management;  5)  engineering  artefacts 
management;  and  6)  evaluation  and  assessments  of  SoS.  Without  a  clear  understanding  of 
these  aspects  and  their  relevance,  architectural  and  engineering  approaches,  including 
SoSE,  may  still  have  difficulties  in  successfully  delivering  complex  military  SoS.  This 
reflects  in  fact  an  urgent  need  of  an  important  ability  in  effective  and  consistent 
conceptualisation  and  contextualisation  for  various  activities  and  tasks  to  be  able  to  work 
collaboratively  in  shared  and  commonly  agreed  contexts  in  consistent,  coherent  and 
responsive  manners. 


3.  SoS  Thinking 

Systems  Thinking  [Checkland,  1999]  offers  a  powerful  perspective,  a  specialized  language, 
and  a  set  of  tools  that  people  can  use  to  address  complex  problems  of  various  systems  in 
the  modern  world.  It  provides  a  way  of  understanding  reality  through  focusing  on  the 
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relationships  among  a  system's  parts,  rather  than  the  parts  themselves.  Also  drawing  upon 
systems  thinking,  as  mentioned  in  the  previous  section,  the  SoSE  community  developed 
methods  and  approaches  to  address  some  SoS  issues  by  combining  them  with  relevant 
disciplines  and  approaches.  However,  some  fundamental  questions  remain  to  be 
considered,  while  facing  multiple  interrelated  SoS  in  a  SoS  problem  space. 

The  high  complexity  of  military  SoS  involves  four  inter-dependent  domains,  namely:  force 
development  &  management,  military  operations,  capabilities  &  systems,  and  processes  & 
activities  conducted  for  development  and  management  of  various  capabilities  and 
systems.  The  high  complexity  is  contributed  from  a  number  of  main  sources  or  by  a 
number  of  factors,  including  diversity,  interdependency,  context,  development  states  and 
technical  statuses  of  SoS,  and  a  variety  of  SoS  activities  and  stakeholders. 

Defence  organisations  face  three  major  challenging  engineering  tasks  related  to  realising 
complex  and  interrelated  military  SoS. 

•  Task  1:  how  to  define  SoS  meaningfully  and  manageably  in  the  military  SoS 
problem  space  and  systematically  identify  and  manage  their  interrelationships; 

•  Task  2:  how  to  cost-effectively  develop  new  SoS  or  evolve  existing  SoS  in  parallel  in 
a  collaborative  manner  in  a  complicated  and  changing  SoS  environment;  and 

•  Task  3:  how  to  effectively  manage  and  operate  many  related  SoS  in  an  integrated 
and  coordinated  manner  throughout  their  lifecycles. 

In  order  to  be  able  to  conduct  these  tasks  in  an  integrated  manner.  Defence  needs  an 
effective  systems  thinking  ability  or  approach  to  help  establish  a  good  understanding  of  a 
SoS  problem  space,  which  can  present  coherent  worldviews  of  multiple  interacting  SoS 
throughout  their  lifecycles,  and  establish  a  foundation  that  will  support  SoSE  research  and 
practice. 

When  applying  systems  thinking  to  a  SoS  problem  space,  an  important  ability,  called  as 
SoS  thinking,  is  needed  to  understand  and  examine  specific  issues  of  SoS,  which  can 
effectively: 

•  conceptualise  a  problem  space  as  a  series  of  wholes  that  are  different  SoS  with 
specified  interdependencies  or  interrelationships; 

•  contextualise  and  provide  understandings  of  multi-type  and  multidimensional 
complexity,  focusing  on  manageability,  context,  interrelationships  and 
interdependencies  between  systems  or  SoS;  and 

•  examine  unintended  consequences  and  potential  states  and  statuses  of  systems  and 
SoS  under  different  development  conditions. 

In  order  to  achieve  an  understanding  of  complexity  of  SoS  problems  and  requirements  for 
SoSE,  SoS  thinking  seeks  both  strategies  and  methods  to  address  these  challenges  and 
considerations  through  specifically  exploring  the  following  main  perspectives: 

1.  Awareness  of  a  SoS  problem  space  with  its  engineering  factors:  A  SoS 

problem  space  can  range  from  a  single  defined  SoS,  a  domain  with  multiple 
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interrelated  SoS,  to  an  organisation  with  multiple  interrelated  domains.  It  should 
be  clearly  identified  since  different  SoS  problem  spaces  need  very  different 
engineering  tasks  and  efforts  for  different  development  requirements  and  issues. 

2.  SoS  categorisation  and  identification:  Understanding  and  management  of  the 
diverse  range  of  SoS  can  be  aided  by  categorising  SoS,  according  to  their  different 
natures  and  features  in  creation,  composition,  formation,  development, 
management  and  operation.  Each  SoS  should  be  identified  meaningfully  and 
manageably  with  its  constituents  in  a  SoS  problem  space,  if  possible,  against  a 
proper  categorisation. 

3.  SoS  interdependency:  The  complex  web  of  SoS  interdependencies  in  various 
contexts  and  conditions  should  be  understood  and  addressed  with  adequate 
concepts,  methods  and  solutions,  lest  it  cause  confusion,  complications  and  even 
chaos  in  SoS  development  and  management. 

4.  SoS  development  states:  SoS  can  be  in  different  development  states  and  go 
through  different  state  transition  paths,  according  to  development  efforts  and 
decisions  made,  which  significantly  increases  the  complexity  of  SoS  activities  and 
engineering.  Given  interdependencies  between  SoS  and  concurrent  development 
activities,  the  development  states,  transition  paths  and  their  associated  issues  are 
important  lifecycle  concepts  in  a  SoS  problem  space. 

5.  SoS  technical  status:  Even  with  the  same  composition  of  constituents,  a  given 
SoS  can  end  up  (or  be  realised)  in  different  technical  statuses  with  different 
operation  features  and  performances,  due  to  different  development  conditions  in 
integration  between  its  constituents  and  other  engineering  factors.  Like  the 
development  states,  SoS  technical  statuses  are  important  engineering  and 
management  issues  in  a  SoS  problem  space. 

6.  SoS  design  relevance  and  paradigm:  In  addition  to  the  difference  to 
conventional  system  design  or  design  of  a  single  SoS,  SoS  design  in  a  SoS  problem 
space  can  be  very  complicated,  with  a  combination  of  multiple  design  tasks 
undertaken  by  different  stakeholders  at  different  stages  of  development.  These 
design  tasks  produce  various  defined  and  required  outcomes  and  design  products 
for  different  aspects  along  with  development  state  transitions  of  those  interrelated 
SoS. 

7.  Extended  SoS  community  of  practice  (CoP):  The  community  interested  in  or 
responsible  for  various  SoS  is  broader  than  one  involved  in  the  traditional  SE  CoP, 
which  includes  not  only  professionals  involved  in  SE,  architecting  and  integration, 
but  also  planners,  analysts  and  other  stakeholders.  Effective  communications, 
organisational  learning  and  knowledge  sharing  through  common  worldviews 
established  across  the  SoS  community  are  essential  to  enable  the  required 
coordination,  orchestration  and  collaboration  of  SoS  activities  to  deliver  responsive 
and  coherent  outcomes. 

Each  of  these  perspectives  offers  a  particular  viewpoint  to  a  SoS  problem  space  through  a 
specific  complexity  lens.  The  applications  of  SoS  thinking  in  military  domains  are 
discussed  in  details  in  the  following  sections,  with  relevant  concepts,  methods  and  metrics 
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introduced  specifically  for  addressing  issues  and  challenges  of  military  SoS.  The  SoS 
thinking  is  an  extension  to  the  systems  thinking  and  a  conceptualisation  approach  to  a  SoS 
problem  space  and  outcomes  of  engineering  factors.  It  is  introduced  to  help  SoS 
development  activities  avoid  dealing  with  a  messy  collection  of  systems  and  hopefully  to 
offer  a  firmer  and  shared  foundation  to  further  develop  and  improve  relevant  disciplines 
and  methodologies.  It  is  not  however  intended  to  be  used  as  an  engineering  practice 
handbook  or  to  replace  those  relevant  engineering  disciplines  and  architectural 
approaches. 


4.  Military  SoS  Problem  Spaces  and  Engineering 

Factors 


Building  of  the  SoS  definition  from  Section  1,  a  SoS  can  be  considered  as  a  set  or 
arrangement  of  systems  that  results  when  independent  and  useful  systems  are  integrated 
into  a  larger  system  that  delivers  unique  capabilities  [DoD,  2004],  SoS  are  characterised  by 
the  design  and  system  principles  [Maire,  1996]  [Adams,  2011],  with  five  distinctive 
features  that  differentiate  them  from  very  large  and  complex  systems: 

•  Operational  independence  of  the  elements 

•  Managerial  independence  of  the  elements 

•  Evolutionary  development 

•  Emergent  behaviours 

•  Geographic  distribution. 

A  collection  of  systems  is  to  be  considered  as  a  SoS,  according  to  the  SoS  definition, 
because  of  the  acknowledgement  to  the  outcomes  resulted  by  two  main  factors.  One  is  the 
compositional  factor  that  is  the  outcome  of  selection  decisions,  which  decides  what  the 
constituent  systems  or  elements  are.  The  other  is  the  engineering  factor  that  determines 
what  arrangements  among  the  constituent  systems  and  elements  are  and  how  they  are 
integrated  or  cooperate. 

In  order  to  meaningfully  and  effectively  assess  how  well  a  SoS  operates  as  a  whole  and 
manage  the  conditions  of  operation  and  technical  status,  a  new  SoS  concept  is  introduced, 
called  as  SoS  Characterisation  of  Operation  and  Technical  Status  (SCOTS).  The  SCOTS 
concept  is  considered  for  each  SoS  identified,  rather  for  any  collection  of  systems  or  a  SoS 
problem  space.  It  can  be  benchmarked  at  4  levels  as  shown  in  Table  1,  according  to  their 
features  in  four  important  aspects.  These  4  levels  are  characterisations  of  technical 
conditions  or  statuses  of  SoS  at  a  given  point  of  time.  These  4  levels  are  determined  by  the 
different  levels  and  outcomes  of  engineering  efforts,  especially  in  the  four  aspects. 

Due  to  the  features  of  SoS  formation  and  development,  it  is  the  engineering  factor  that 
results  in  a  SoS  at  a  particular  SCOTS  level.  The  SCOTS  levels  can  thus  indicate  different 
levels  of  efforts  made  by  the  engineering  factor  and  quality  of  outcomes  delivered  by  the 
efforts.  SoS  performance  and  quality  (or  how  well  it  performs  or  operates)  as  a  whole,  in 
other  words,  is  the  outcomes  generated  by  four  main  tasks  contributing  the  engineering 
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factor,  that  is,  planning,  design,  development  and  management.  The  engineering  factor 
has  on-going  impact  to  the  performance  of  SoS  throughout  its  lifecycle.  As  discussed  in  the 
later  sections,  it  is  the  engineering  factor  that  not  only  results  in  SoS  at  a  particular  SCOTS 
level  but  also  can  potentially  make  a  given  SoS  change  in  its  technical  status  or  change 
from  one  SCOTS  level  to  another.  Because  of  features  and  requirements  of  military 
systems,  in  principle,  no  military  SoS  should  operate  at  the  SCOTS  level  0. 

In  the  real  world,  SoS  problems  vary  from  a  single  SoS  to  a  SoS  problem  space  where 
many  SoS  and  systems  are  interrelated  and  interdependent  in  various  ways,  as  often 
observed  in  defence  organisations.  Military  SoS  in  a  human-cyber-physical  environment 
are  ubiquitous  and  cross  many  areas  within  Defence,  rather  than  only  for  areas  related  to 
systems  development.  Many  existing  SoS  concepts,  principles  and  processes,  which 
consider  mainly  a  single  SoS,  are  not  applicable  to  address  engineering  issues  involving 
multiple  SoS  problems.  Thus,  there  are  gaps  in  the  theory  and  methodology  that  need  to 
be  filled  in  order  to  make  SoS  concepts  and  methodologies  work  in  situations  facing  a  SoS 
problem  space.  In  other  words,  there  is  a  need  of  shifting  to  a  new  way  of  thinking,  that  is, 
from  considering  a  single  SoS  to  dealing  with  multiple  interdependent  SoS.  This  new 
thinking  strategy  offers  different  perspectives  to  view  issues  and  requirements  of  SoS 
architecture  and  engineering. 

Table  1  SCOTS  Matrix 


SCOTS 

Levels 

Conditions  of 
constituent’s 
involvement 

Conditions  of  cooperation  and 
integration/interoperability 
between  constituents 

Emergent 
Behaviours  or 
joint  effects 

Cooperation 
uncertainty 
or  disorder 

SCOTS 

Level  3 

Roles/functions/ 
capacity  designed 
adequately,  tested 
and  certified  as 
required 

Complete  integration  of  processes, 
information  and  systems, 
adequately  designed  cooperation, 
defined  interoperability 
requirements  (LISI  Level  3  or 
above)  specified  in  architectural 
views 

Adequately 
designed,  assessed 
and  facilitated,  and 
highly  achievable, 
mitigation  solutions 
for  negative  ones 

Very  low  level 

with  solutions 

to  cope  with, 

except 

designed 

operational 

flexibility 

SCOTS 

Level  2 

Roles/functions/ 
capacity  designed; 
involvements 
required  and  well 
coordinated 
based  on  design 
or  certification 

Partial  integration  of  systems  and 
information,  confirmed  process 
awareness  and  coordination, 
defined  cooperation,  partially 
defined  interoperability  above  LISI 
Level  2  required 

Expected, 
assessed,  and 
achievable  if 
coordinated  and 
enabled  by  required 
integration,  control 
and  management  of 
negative  ones 

Low  level  with 
solutions  to 
control  and 
manage 

SCOTS 

Level  1 

Roles/functions 
planned, 
involvements 
expected  and 
based  on 
agreements 

Agreements  on  cooperation, 
common  sense-based  awareness  of 
processes,  cooperation  based  on 
human-in-loop  and  existing 
conditions,  LISI  level  1  required 

Envisaged  and 
analysed  with 
expectation  but  no 
assurance,  mainly 
human-driven 

Medium  level, 
anticipated  but 
not  fully 
appreciated 

SCOTS 

Level  0 

Not  planned,  not 

coordinated, 

possible 

involvements 

based  on 

availability 

Ad  hoc  cooperation  based  on 
willingness,  interoperability  not 
specified,  LISI  Level  0  in  worst 
cases 

Envisaged  or 
surprises  and  not 
well-prepared 

High  level  and 
uncontrolled 

In  military  domains  where  there  are  nested  concepts  and  inter-related  purposes,  SoS 
problem  spaces  facing  various  activities  are  considered  in  three  typical  cases: 
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•  Case  1:  where  there  is  a  single  well-defined  SoS  in  isolation  from  others  or  with 
clearly  specified  interfaces  and  relations  to  the  external  world; 

•  Case  2:  where  multiple  SoS  co-exist  and  are  inter-related,  may  partly  overlap  each 
other,  and  are  planned  and  developed  in  parallel;  and 

•  Case  3:  where  there  are  multiple  domains  of  Case  2  that  overlap  or  are  interrelated 
in  an  organisation  or  crossing  organisations. 

Despite  of  the  unawareness  or  mainly  focusing  on  specific  systems,  many  areas  or 
domains  defined  for  management  purposes  in  Defence  actually  fall  into  the  situations  of 
Case  2,  such  as  acquisition  projects,  programs,  capability  development  or  operations.  Each 
of  them  faces  a  specific  problem  space  of  systems  or  SoS,  as  discussed  later  on.  These  areas 
or  domains  are  often  overlapping  or  interdependent,  which  becomes  the  situation  of  Case 
3.  SoS  engineering  issues  and  challenges  are  very  different  in  these  three  cases.  For  Cases  2 
and  3,  there  are  some  important  issues  and  aspects,  such  as: 

•  inter-relationships  between  SoS 

•  integration  of  multiple  SoS 

•  context  dependency 

•  relevance  and  coordination  of  design  and  development 

•  architectures  or  artefacts  management  crossing  SoS. 

These  specific  engineering  requirements  and  issues  in  Cases  2  and  3  are  not  well  explored 
and  addressed  by  existing  SoS  concepts,  studies,  engineering  practice  and  architectural 
approaches.  (Note  enterprise  architectural  frameworks,  which  are  applicable  mainly  for 
information  and  business  management  systems,  do  not  consider  specifically  SoS  in 
human-cyber-physical  environments.) 

Understanding  and  clarifying  the  case  of  a  SoS  problem  space  is  thus  the  first  thing  that 
SoS  thinking  suggests  all  SoS  activities  and  SoSE  practice  need  to  look  at.  Simply 
considering  any  collection  of  systems  as  a  'SoS'  can  potentially  cause  a  number  of  issues 
and  problems  in  conceptualisation.  First,  it  compromises  the  conditions  of  the  SoS 
definition  and  lacks  considerations  of  system  rationale  and  purposes.  Secondly,  this 
conceptualisation  could  face  serious  issues  of  manageability  and  complexity  in 
architecture  if  the  collection  involves  a  large  number  of  interdependent  systems.  Thirdly,  it 
increases  the  difficulty  and  complexity  of  architecting  or  application  of  architectural 
approaches  or  frameworks  if  they  do  not  provide  clear  guidance  on  how  to  identify  SoS 
and  how  to  deal  with  multiple  SoS. 

In  Cases  2  and  3  the  complexity  of  their  interdependencies  and  interrelationships  can 
become  conceptually  and  contextually  unmanageable  if  they  are  not  properly  specified, 
engineered  and  managed.  Such  a  messy  collection  of  systems,  from  a  viewpoint  of 
architecture  and  integration,  is  a  failure  of  engineering  and  management  for  an 
organisation.  The  consequence  of  becoming  a  messy  collection  is  great  difficulties  to 
effectively  achieve  required  integration  and  interoperability,  and  to  maintain 
sustainability.  A  messy  collection  of  interrelated  systems  or  its  associated  high  complexity 
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often  results  in  a  high  level  of  risks  for  projects  and  capability  developments,  as  pointed 
out  by  many  Technical  Risk  Assessment  (TRA)  reports  for  defence  acquisition  projects. 

In  order  to  prevent  such  multiple  SoS  problems  turning  into  a  'mess'  a  critical  task  is  to 
effectively  conceptualise  SoS  problem  spaces,  namely,  to  purposefully  and  meaningfully 
identify  and  define  multiple  related  and  interdependent  SoS,  and  systematically  and 
effectively  deal  with  their  complicated  relationships. 

In  order  to  adequately  deal  with  SoS  problem  spaces  and  their  engineering  issues,  an 
important  thinking  ability  is  required  for  all  SoS  activities  in  two  aspects,  that  is, 
conceptualisation  and  contextualisation  (or  context  management).  These  two  aspects  are 
critical  for  people  and  activities  to  effectively  work  together,  which  are  further  explored 
when  the  other  perspectives  of  SoS  thinking  are  discussed  in  the  following  sections.  This 
thinking  ability  needs  to  ensure  a  SoS  problem  space  to  be  conceptually  maintained  as  a 
managed  and  sustainable  SoS  world,  as  shown  in  Figure  2,  rather  than  becoming  a  messy 
collection  of  systems. 


A  managed  and 
sustainable 
SoS  world 


A  Collection  of 
interdependent 
systems 


A  messy  collection 
of  interrelated  or 
interdependent 
systems 


Increase  of  integration  and  interoperability 


Changes  or  evolution 


Figure  2  A  risk  for  a  collection  of  interdependent  and  interrelated  systems  to  become  messy 


5.  SoS  Categorisation  and  Identification 

A  SoS  needs  to  be  clearly  identified  with  its  constituents  in  conceptualisation,  and 
then  if  required,  designed  or  implemented  accordingly.  Apart  from  the  SoS 
definition,  there  has  been  no  standard  or  clear  guidance  on  how  to  identify  a  SoS  in 
the  current  architecture  or  engineering  practice.  Inconsistent  or  ad  hoc 
identification  of  SoS  (including  no  identification)  in  a  SoS  problem  space  is 
problematic  and  can  causes  major  confusions,  problems  and  difficulties  in 
architecture  and  engineering  practice.  The  rationale  to  identify  SoS  in  a  problem 
space,  suggested  by  SoS  thinking,  is  based  on  the  following  considerations: 
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•  There  is  a  need  (such  as  a  good  practice  and  ability  in  conceptualisation  and 
contextualisation  for  engineering  purposes  or  management  practice)  and  there  are 
benefits  to  consider  and  identify  a  SoS  of  interest  (e.g.,  if  SoS  concepts  can  help 
address  engineering  challenges  as  discussed  in  this  report); 

•  A  SoS  should  be  identified  with  its  constituents  in  accordance  to  the  SoS  definition 
and  can  be  assessed  in  its  technical  status  according  to  SCOTS  levels; 

•  SoS  identification  can  help  clarify  contexts,  scopes  and  responsibilities; 

•  SoS  identification  should  consider  both  manageability  and  complexity; 

•  SoS  identification  should  enable  definitions  and  specifications  of  interdependencies 
and  interrelationships  between  different  SoS; 

•  SoS  identification  should  be  based  on  features  of  formation,  composition, 
development  and  lifecycle  of  SoS  in  a  specific  domain;  and 

•  SoS  identification  should  be  made  consistently  within  an  organisation  if  possible 
and  agreed  by  relevant  stakeholders  as  required. 

Given  the  diversity  of  SoS  and  SoS  issues,  it  is  unrealistic  to  think  or  believe  that  a  single 
architecture  methodology  or  the  same  engineering  practice  would  be  suitable  for  different 
SoS  and  their  complicated  engineering  issues.  The  awareness  of  SoS  diversity  leads  to  the 
consideration  of  SoS  categorisation  that  can  potentially  bring  benefits  to  understanding  of 
SoS  and  requirements  for  its  engineering  practice.  An  appropriate  categorisation  can  offer 
a  basis  to  consider  different  and  appropriate  concepts,  methods,  processes  and  solutions 
for  different  SoS.  Such  a  practice  encourages  and  enables  development  activities  to  treat 
SoS  and  their  issues  differently  according  to  the  requirements  associated  with  their  natures 
and  features  in  creation,  composition,  development  states  and  technical  statuses. 

Military  SoS  appearing  in  a  human-cyber-physical  systems  environment  can  be  considered 
in  the  following  main  categories  according  to  features  in  composition,  design, 
management  and  operation: 

•  Information-based  SoS  (I_SoS)  is  based  on  joint  networks  and  provides  functions 
and  information  services  by  its  constituent  information  systems  which  are 
integrated  through  their  interfaces,  interactions,  information  flows  and  integration 
solutions. 

•  Platform-based  SoS  (P_SoS)  encompasses  the  various  on-board  systems,  force 
elements  and  SoS  that  are  physically  located  and  operated  on  a  specific  platform 
but  deliver  different  functions  and  capabilities  in  a  joint  and  integrated  manner  in 
operations  (note  that  military  bases  and  infrastructures1  can  be  viewed  as  special 
cases  of  platforms). 

•  Capability-based  SoS  (C_SoS)  is  a  specific  set  of  force  elements,  capabilities  and 
systems  to  form  a  specific  military  capability  such  as:  air  defence;  sea  denial; 
amphibious;  or  intelligence,  surveillance  and  reconnaissance  (ISR). 
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•  Unit  (of  force)-based  SoS  (U_SoS)  is  a  defined  organisational  unit  with  capability 
elements  and  systems  designed  for  conducting  force  and  operation  management 
and  delivering  warfighting  capability,  which  are  usually  generated  in  the  force 
planning  and  generation  processes. 

•  Operation-based  SoS  (0_SoS,  also  called  Mission-based  SoS  or  M_SoS)  includes 
all  participating  force  and  capability  elements,  systems  and  their  relations  that 
jointly  form  an  operation  context.  The  0_SoS  is  often  partly  described  or  defined  in 
a  text-based  form  in  doctrines,  operation  plans  or  concepts  of  operation  documents, 
or  presented  as  a  mission  thread  or  in  an  operational  view  of  architecture. 

These  five  categories  are  initially  introduced  as  a  reference  based  on  the  rationale  and 
considerations  for  SoS  identifications.  Among  these  five  categories,  some  (such  as  I_SoS,  P- 
SoS  or  C_SoS)  are  relatively  familiar  to  the  engineering  community  as  systems,  or 
sometime  have  been  considered  as  SoS  in  practice.  Some  (i.e.  0_SoS  and  U_SoS)  are 
familiar  as  concepts  or  areas  for  military,  but  not  treated  as  SoS,  except  in  some  case 
studies.  The  categorisation  introduced  in  such  a  manner,  in  addition  to  the  considerations 
of  SoS  identification  rationale,  has  its  specific  significance  in  two  folds.  First,  it  can  enable 
SoS  activities  or  engineering  practice  to  target  specific  SoS  for  design,  development 
management  and  assessments,  in  order  to  avoid  dealing  with  either  a  'super'  SoS  or  a 
messy  collection  of  systems.  Secondary,  it  can  ensure  that  responsibilities  of  various 
stakeholders  in  development  and  management  can  be  adequately  mapped  to  specific  SoS. 

A  list  of  SoS  examples  considered  in  different  categories  is  given  in  Table  2.  Some  of  these 
categories  can  span  multiple  levels  of  scale  in  the  same  category  if  required.  For  example, 
an  U_SoS  can  range  from  a  section  of  soldiers  to  divisions  in  Army,  or  from  capability 
element  groups  to  task  groups  in  Navy.  Similarly,  an  I_SoS  may  range  from  a  suite  of 
integrated  software  to  a  force  wide  information  network. 

Table  2  Examples  of  military  SoS  in  different  categorise 


Name 

Acronym 

Category 

Battlespace  Management  Systems 

BMS 

I SoS 

Combat  Management  System 

CMS 

I SoS 

Theatre  Broadcast  System 

TBS 

I SoS 

Defence  Information  Environment 

DIE 

I SoS 

Navy  Info.  Management  Portal 

NIMP 

I SoS 

Amphibious  Assault  Ship 

LHD 

P SoS 

Joint  Strike  Fighter 

JSF 

P SoS 

Bushmaster  (Protected  Mobility 
Vehicle) 

PMV 

P_SoS 

Ballistic  Missile  Defence  System 

BMDS 

C SoS 

Future  Combat  Systems 

FCS 

C SoS 

Mine  Countermeasure  capability 

MCM 

C SoS 

Amphibious  capability 

C SoS 
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Air  Operation  Centre 

AOC 

U SoS 

Army  Company/ Brigade 

Coy/Bde 

U SoS 

Navy  Force  Element  Groups 

FEG 

U SoS 

Amphibious  Assault 

0 SoS 

Surface  operation  of  a  task  group 

0 SoS 

Combat  Air  Patrol  Operation 

CAPO 

0 SoS 

Battegroup  in  deployment 

BG 

0 SoS 

Task  Force  in  deployment 

TF 

0 SoS 

The  military  SoS  categorisation  provides  a  reference  and  guidance  to  the  community  to 
meaningfully  and  consistently  identify  SoS  in  a  military  domain.  New  categories  or 
changes  can  be  considered  and  introduced  if  needed.  How  SoS  in  these  categories  could  be 
effectively  developed  and  maintained  in  terms  of  their  required  SCOTS  levels  is  a  question 
yet  to  be  addressed.  Through  using  SoS  thinking,  each  of  these  categories  offers  a  specific 
basis  to  explore  important  features  and  requirements  of  specific  SoS  in  development  and 
management. 

Adequate  identification  of  all  important  SoS  in  a  SoS  problem  space  is  critical  and  can 
provide  a  shared  basis  to  contextualise  engineering  and  management  activities,  and  to 
control  and  manage  complexity.  It  is  the  conceptualisation  with  SoS  identification,  as 
explored  in  the  other  thinking  perspectives  that  makes  many  engineering  issues  be  more 
clearly  focused  on  specific  SoS,  including  SoS  interdependency  identifications, 
development  control  and  management,  assessments  and  lifecycle  management. 

Defence  acquisition  programs  and  projects  are  usually  responsible  for  development  and 
delivery  of  I_SoS,  P_SoS  and  C_SoS  after  planning  and  studies  by  Strategy,  Capability  and 
Sustainment  Group  (CASG)  and  DST  Group.  Traditional  SE  practice  applied  in  defence 
acquisition  is  thus  focussed  mainly  on  development  of  systems,  platforms  and  capabilities, 
namely,  SoS  in  these  three  categories.  In  the  current  practice,  there  is  no  explicit 
consideration  of  either  0_SoS  or  U_SoS  in  the  current  SE  practice.  It  may  be  clear  in 
defence  organisations  who  should  be  responsible  for  operations  and  force  management. 
But  it  becomes  unclear  and  confusing  when  asking  how  and  when  they  should  be 
developed  in  an  engineering  manner  for  joint  force  integration,  and  how  they  are  related 
to  SoS  in  other  categories  in  architecture  and  engineering  practice.  SoS  thinking  suggests  a 
different  approach  to  force  development  and  operation  design  through  conceptualising 
adequate  operations  and  force  elements  as  0_SoS  [Chen,  2016]  and  U_SoS. 

As  discussed  in  the  previous  section,  there  are  often  multiple  interrelated  SoS  in  different 
categories  in  a  military  domain  (or  a  SoS  problem  space).  As  an  example,  a  number  of 
different  viewpoints  of  potentially  different  SoS  in  the  domain  of  Amphibious  are  shown 
in  Figure  3,  which  have  different  constituents  in  the  composition  (that  is,  (a)  presents  a 
C_SoS;  (b)  is  a  view  of  an  I_SoS  deployed  in  amphibious  operations;  (c)  shows  a  P_SoS; 
and  (d)  is  a  view  of  an  Army  U_SoS  deployed  in  an  amphibious  operation). 
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■Diagrams  are  sourced  from  JAC1T  Presentation 
for  LHD  C4I  Capability  2026 


Figure  3  Multiple  military  SoS  in  Amphibious 

In  addition  to  the  missing  of  the  guidance  on  conceptualisation  when  applied  to  a  SoS 
problem  space,  many  engineering  or  architectural  approaches  or  frameworks,  however, 
also  do  not  make  distinctions  between  SoS  in  different  categories.  They  thus  lack  specific 
considerations  for  different  features  of  SoS  in  different  categories  in  development, 
integration  and  management.  In  the  current  practice,  moreover,  SoS  in  some  categories  are 
often  not  considered  as  SoS,  and  consequently  not  treated  accordingly  in  an  engineering 
manner  in  development.  As  a  result,  their  development  requirements  (including 
architectures)  and  lifecycle  management  are  not  adequately  addressed.  A  further  study  on 
the  development  features  and  requirements  based  on  these  categories  is  needed  in  order  to 
help  Defence  guide  identification  of  SoS  and  establish  adequate  SoSE  for  SoS  in  different 
categories. 

Without  considering  the  existence  of  multiple  SoS,  engineering  or  architecture  activities 
conducted  in  parallel  often  encounter  uncontrolled  and  on-going  development  conflicts, 
gaps  or  holes,  and  incoherent  or  uncoordinated  development  of  relevant  architectures,  due 
to  missing  identification  of  some  SoS  concerned,  as  discussed  in  Section  9.  Based  on  SoS 
categorisation  and  identification,  many  engineering  issues  and  requirements  can  be  well- 
contextualised  and  considered  specifically  against  particular  SoS  identified  in  those 
categories.  For  example,  as  shown  in  Table  3,  the  further  considerations  on  architecture, 
design  and  integration  can  be  given  specifically  to  SoS  in  different  categories,  in  addition 
to  the  general  guidance  from  architectural  approaches. 

Given  that  many  existing  architectural  approaches  or  frameworks  do  not  clear  guidance 
on  how  to  identify  SoS  in  a  SoS  problem  space,  SoS  Thinking  specifically  suggests 
architecture  developers  and  other  stakeholders  be  aware  of  and  consider: 

1.  development  activities  may  need  to  deal  with  multiple  SoS  with  different 
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architecture  and  design  requirements  based  on  their  categories  as  indicated  in 
Table  3; 

2.  for  each  SoS  there  may  be  multiple  potential  higher  SoS,  or  operation  contexts  that 
are  SoS  as  well  by  themselves,  and  should  be  shared  with  different  constituent 
systems  or  SoS; 

3.  how  design  activities  or  architectures  of  different  SoS  are  related;  and 

4.  who  should  be  responsible  for  design  of  these  SoS,  in  particular  0_SoS  and  U_SoS 
(in  particular  those  related  to  mission-based  C2  functions  and  processes,  and 
specific  warfighting  functions,  such  as  joint  fires  and  situation  awareness)  and 
when. 

Table  3  Categorisation-based  SoS  design  aspects  and  architecture  requirements 


SoS 

Category 

SoS  Design  Aspects  and  Architecture  Requirements 

Structure/ 

Composition 

Functions 

/Roles 

Process 

Networks 

Info 

Integration 

0_SoS 

•  ov 

•  C2  structure 
■  Constituent 

systems  and 
elements 

•  Task  lists 

•  Mission  effects 

■  Logistics 

■  Emergent 
behaviours 

•  C2  process 

•  Op  vignettes 

•  Op  phases 

•  Op  control 

•  SOP 

•  Networks 

•  Comms. 

•  Standards 
■  Security 

•  Info  flows 

•  IER 

•  Interfaces 
to  external 

■  Crossing 
elements  or 
systems 

■  Both  internal  and 
external 

U_SoS 

•  Org. 

■  Cap  elements 

■  Systems 

•  Security 

•  OVs(of  0_SoS) 

■  Tasklists 

•  FPS 

•  Logistics 

•  C2  process 

•  Planning 

•  Mgt  process 

•  SOP 

•  Networks 
■  Comms. 

•  Standards 

•  Security 

•  Info/data 

■  Info  flows 

•  IER 

•  Security 

•  Crossing 
elements  or 
systems 

•  Both  internal  and 
external 

P_SoS 

•  Physical 

•  Space 

■  Standards 

•  Elements 

•  OVs(of  0_SoS) 

•  Deployment 
patterns 

•  FPS/M0E/M0P 

•  Op  process 

•  SOP 

•  Networks 

•  Standards 
■  Others 

•  Info  flows 

•  IER 

■  Interfaces 

•  Security 

■  Cooperation 

•  Partnerships 

•  Coordination 

C_SoS 

•  Elements 

•  Systems 

•  Standards 

•  OVs(of  0_SoS) 

•  Deployment 
Patterns 

•  FPS/MOE/MOP 

•  Mgt  process 

•  Deployment 
processes 

•  SOP 

■  Networks 

•  Standards 

•  Others 

■  Info/data 

•  Info  flows 

•  IER 

■  Security 

•  Interoperability 
■  Cooperation 

•  Security 

l_SoS 

•  Systems 
■  Software 

•  OVsfof  0_SoS) 

•  Fund.  Specs. 

■  Deployment 

patterns 

*  Applications 

•  Networks 

■  Standards 

•  Security 

•  Info/data 

•  Info  flows 

•  Interfaces 

•  Security 

•  Systems 

•  Software 
■  Security 

The  categorisation  of  military  SoS  provides  a  reference  and  guidance  to  consistent 
identification  or  conceptualisation  of  SoS.  It  also  offers  a  foundation  for  Defence  to 
consider  how  to  achieve  effective  military  SoS  governance  [Keating,  2014]  and  how  to 
more  systematically  develop  and  effectively  manage  SoS  in  different  categories,  according 
to  their  features,  and  to  further  explore  other  more  complicated  SoS  development  issues  as 
discussed  in  the  following  sections. 

The  terms,  such  as  capability,  platform,  force  elements/ units  and  operations,  are  familiar 
to  Defence  community,  and  used  widely  in  acquisition,  development  and  management. 
Why  are  they  suggested  to  be  considered  as  SoS?  While  facing  multiple  interdependent  or 
interrelated  systems,  first,  development  activities  often  face  difficulties,  inconsistency  and 
uncertainties  in  defining  scopes/ contexts,  identifying  interdependencies,  specifying 
design  products  and  integration  requirements,  coordinating  relevant  activities,  and 
assessing  development  outcomes.  Identifying  them  as  adequate  SoS  can  effectively 
conceptualise  a  SoS  problem  space  and  provide  a  good  context  management  solution.  It 
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can  change  complexity  control  and  development  management  from  whole  projects  or 
whole  capability  programs  to  directly  against  individual  SoS.  Such  a  change  can  make  a 
big  difference  for  development  activities  and  processes  as  discussed  in  the  following 
sections,  thanks  to  many  concepts,  methods  and  metrics  introduced  with  SoS  thinking.  In 
other  words.  Defence  can  benefit  significantly  by  effectively  using  SoS  concepts  in  force 
and  capability  development  and  engineering  practice  as  discussed  in  the  following 
sections. 

However,  not  every  capability,  platform,  information  system,  force  unit  or  operation  needs 
to  be  considered  as  a  SoS.  Given  the  rationale  of  considerations  for  military  SoS 
identification,  it  is  suggested  that  only  those,  which  appear  to  need  special  attention  in  two 
aspects  or  areas,  should  be  considered  as  SoS.  One  is  high  complexity  in  development  and 
management  due  to  high  requirements  in  integration  and  interoperability.  The  second  is  a 
need  of  systematic  engineering  practice  for  architecture  development  and  evolution 
management.  Using  SoS  thinking.  Defence  can  consistently  treat  them  (namely,  capability, 
platforms,  information  systems  and  force  units)  as  adequate  SoS  but  in  different  categories 
for  development,  integration  and  management.  Such  a  practice  effectively  makes  it 
possible  to  systematically  and  consistently  conceptualise  and  contextualise  many  domains 
of  development,  management  and  operations. 

The  term,  'capability',  is  over-utilised  and  means  many  different  things  to  different  people. 
Some  warfighting  concepts  or  functions,  such  as  C4ISR,  joint  fires,  battlespace  awareness, 
battlespace  manoeuvre,  force  protection  and  logistics,  are  sometimes  also  called  as 
'capability'.  They  are  in  fact  special  context-based  functions,  emergent  behaviours  or 
requirements  (as  indicated  in  Table  3)  of  SoS  in  different  categories  (especially  0_SoS), 
rather  than  SoS  by  themselves.  There  are  also  cases  where  some  capability  (or  C_SoS,  for 
example.  Amphibious)  is  considered  mainly  for  planning,  acquisition  and  management 
purposes  since  their  constituents  (often  subsets)  are  organised  or  arranged  as  specifically 
designed  particular  deployment  patterns  (subsets  of  the  C_SoS)  for  real  operations. 

Such  categorisation  of  SoS  can  help  stakeholders  (from  both  the  defence  and  industry) 
understand  the  nature  of  SoS  they  are  facing  and  their  responsibilities  in  development  and 
management.  It  also  increases  awareness  of  SoS  issues  within  defence  organisations  and 
can  lead  to  consideration  of  changes  and  improvements  in  relevant  processes  of  force  and 
capability  planning  and  development,  towards  a  holistic  and  joint  engineering  practice 
across  military  SoS  problem  spaces.  More  detailed  discussions  on  the  justifications  of  the 
categorisation  and  requirements  in  development  and  management  of  SoS  in  each  category 
will  be  reported  in  separate  reports  [Chen,  2016]. 


6.  SoS  Interdependencies 

Each  SoS  has  its  own  web  of  interdependencies  with  or  relationships  to  others  in  a  SoS 
problem  space.  (For  the  purpose  of  a  uniform  treatment,  interdependencies  between  a 
system  and  SoS  can  be  modelled  in  the  same  manner  as  between  SoS,  that  is,  considering  a 
system  as  a  SoS  in  its  simplest  form.)  These  interdependencies  or  relationships  are 
important  to  a  SoS.  They  have  significant  impact  on  its  effectiveness  and  performance  in 
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operation,  and  thus  should  be  treated  adequately  in  planning  and  development  in  an 
engineering  manner. 

Relationships  between  different  SoS  both  internal  and  external  are  important  features  of 
military  SoS.  If  only  considering  the  SoS  definition,  a  SoS  of  interest  may  have 
relationships  with  other  SoS  in  three  different  ways,  as  illustrated  in  Figure  4: 

•  internally,  it  may  have  a  number  of  constituent  systems  or  SoS  that  are  either  fully 
or  partially  (that  is,  parts  of  a  (distributed)  SoS)  aggregated  with  others  into  the 
SoS  (Note  these  constituent  SoS  or  their  parts  can  also  constituents  to  other  SoS); 

•  hierarchically,  it  may  be  'part-of'  (i.e.  a  constituent  SoS)  or  contribute  to  other 
'higher'  SoS;  and 

•  externally,  it  may  interact,  interoperate  or  partner  with  a  number  of  lateral  SoS. 


Figure  4  A  generic  model  of  the  relationship  iveb  of  a  SoS  of  interest. 

In  a  SoS  problem  space,  any  relationship  or  interdependency  links  two  systems  or  SoS 
identified  with  sematic  meanings.  The  relationship  web  of  SoS  is  further  semantically 
complicated  by  the  complex  relationships  between  military  SoS  in  different  categories,  and 
can  be  captured  in  a  categorisation-based  reference  model  as  illustrated  in  Figure  5.  They 
appear  in  various  forms  involving  SoS  in  different  categories,  as  indicated  by  arrow  lines 
from  a  SoS  in  one  category  to  another  SoS  in  either  the  same  category  or  different  ones. 
The  categorisation-based  reference  model  provides  further  guidance  in  a  military  domain 
to  help  identify  all  potential  constituent  systems  or  SoS  for  each  SoS  identified.  Different 
relationships  (e.g.  'Part-of',  'Contribute-to',  'Be-deployed-to',  'Be-stationed-on',  'Be- 
transported-by'  or  'Be-used-by')  indicate  potential  and  different  architecture  issues  and 
integration  requirements.  Some  relationships  are  on-going.  Others  may  be  optional  or 
required  as  needed. 
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Be-part-of  / 


Figure  5  Categorisation-based  reference  model  for  interrelationship  and  interdependency  between 
military  SoS 

Two  interdependency  reference  models  (Figures  4  and  5)  can  joint  guide  the  identification 
of  interdependencies  between  SoS.  For  instance,  an  I_SoS  (e.g.  a  battlespace  awareness 
system)  can  be  stationed  (as  a  constituent)  on  a  P_SoS  (e.g.  an  amphibious  warship  or  a 
land  vehicle)  and  crosses  a  number  of  SoS;  a  P_SoS  (such  as  a  submarine)  can  contribute  to 
an  intelligence,  surveillance  and  reconnaissance  (ISR)  capability  (or  a  C_SoS);  and  several 
SoS  in  other  categories  can  be  jointly  deployed  to  an  O-SoS  (as  constituents).  Some  land 
vehicles  need  to  be  transported  by  a  navy  ship.  It  is  the  operation  context  (0_SoS)  or 
operation  requirements  that  determine  which  SoS  in  these  categories  and  what 
relationships  are  involved  and  should  be  addressed  accordingly  as  required.  Many  of 
these  relationships  and  interdependencies  are  currently  not  adequately  handled  either  in 
traditional  SE  or  by  relevant  disciplines.  In  particular  for  relationships  between  different 
SoS,  they  are  neither  issues  of  individual  constituent  systems  nor  required  as  formal 
outcomes  of  SoS  design,  according  to  the  current  practice  guidance. 

Lateral  SoS  (or  systems)  are  those  which  may  interact  or  partner  with  the  SoS  of  interests 
and  have  some  impact  and  constraints  to  operations,  but  are  totally  controlled  and 
managed  by  others.  However,  these  lateral  SoS  may  also  contribute  to  the  same  higher 
SoS.  In  other  words,  both  SoS  are  deployed  to  (or  constituents  of)  the  same  0_SoS.  A 
lateral  relationship  between  two  SoS  indicates  potential  interactions,  information  flows 
and  interoperability,  which  need  to  be  articulated  and  captured  as  integration  needs  in 
right  contexts. 

The  number  and  semantic  meanings  of  these  relationships  or  interdependencies  crossing 
various  SoS  in  those  categories  are  the  main  contributors  to  the  SoS  complexity.  The 
number  increases  dramatically  as  the  numbers  of  constituent  systems  and  relevant  SoS 
increase,  as  observed  in  joint  operations  or  development  of  integrated  capabilities.  The 
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consequence  of  this  increase  is  difficulties  and  problems  for  architecting  and  development 
if  relationships  or  interdependencies  are  unspecified  and  unmanaged.  Thus, 
understanding  and  managing  these  SoS  relationships  becomes  a  critical  issue  of  military 
SoS  analysis,  engineering  and  management. 

The  relationships  complexity  of  military  SoS  can  be  further  explored  or  better  controlled 
and  managed  when  the  reference  model  in  Figure  5  is  split  into  five  sub-models  as  shown 
in  Figure  6.  They  illustrate  potential  relationships  between  a  SoS  in  each  category  and 
other  SoS  in  the  same  and  different  categories.  Each  of  these  sub-models  helps 
stakeholders  directly  identify  and  capture  interdependencies  of  a  given  SoS  to  other  SoS  in 
a  SoS  problem  space.  These  category-based  sub-reference  models  can  be  used  by  SoS 
stakeholders  and  activities  to  identify  engineering  contexts  for  all  SoS  identified  and 
concerns  with  their  relevant  interdependencies. 


Figure  6  Sub-reference  models  between  military  SoS 

These  relationships  can  be  further  specified  and  explored  through  considering  domain 
knowledge  and  relevant  engineering  needs  and  management  rules.  In  an  engineering 
practice,  definitions  and  specifications  of  these  relationships  implicitly  express  potential 
architecture  or  integration  requirements  in  structures,  functions  and  information  between 
relevant  SoS.  These  interdependency  descriptions  thus  need  to  be  addressed  in  various 
forms,  including  requirements,  architectures,  interface  specifications  and  design, 
configuration  charts,  or  even  doctrines  or  operational  manuals.  Engineering  and 
management  concerns  and  issues  associated  with  these  relationships  and  their 
implementation  are  yet  to  be  formally  examined  by  relevant  disciplines  as  the  part  of  SE 
practice  for  Case  2  and  Case  3  of  SoS  problems.  Adequate  methods,  metrics  and  solutions 
or  tools  should  be  introduced  to  deal  with  SoS  interdependencies  and  relationships. 
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Based  on  the  identifications  of  SoS,  through  using  Figures  5  and  6,  each  SoS  has  its  web  of 
SoS  interdependencies  or  interrelationships,  which  defines  the  engineering  context.  This 
context  provides  not  only  a  holistic  view  for  its  engineering  scope  and  activities,  or 
awareness  shared  by  the  stakeholders  on  the  relevant  relationships  or  interdependencies 
of  SoS  concerned,  but  also  an  effective  measure  to  control  and  manage  complexity. 

These  relationships  also  come  with  certain  information  on  development  statuses  and 
technical  conditions,  such  as  availability  of  system/ SoS  and  development/  integration 
progresses  and  quality,  which  may  change  over  time  due  to  engineering  progresses  and 
management  decisions.  These  relationships  and  their  development  statuses  have  great 
impact  on  the  behaviours  and  performance,  or  technical  statuses,  of  a  SoS.  This  particular 
perspective  of  SoS  thinking  leads  to  one  of  main  tasks  that  should  be  conducted  by  SoSE 
teams,  that  is,  engineering  artefacts  management  [Chen,  2015].  It  is  carried  out  to  ensure 
these  relationships  and  interdependencies  between  SoS  with  their  development  statuses  to 
be  first  conceptually  captured  as  engineering  artefacts  and  then  to  be  addressed 
adequately  throughout  lifecycles  across  SoS  as  required. 

Conducting  identifications  of  both  SoS  (including  their  key  stakeholders)  and  their 
interdependencies  fulfils  the  task  of  conceptualisation  of  SoS  thinking  to  a  SoS  problem 
space.  Semantics  captured  with  the  interdependencies  and  relationships  between  SoS 
provides  relevant  stakeholders  with  a  context  to  consider  their  specific  perspectives  or 
worldviews  to  these  SoS,  including  engineering  (development  and  integration), 
management,  technical,  personnel,  financial  and  legal.  Through  these  interdependencies 
and  relationships  identified,  stakeholders  can  more  effectively:  1)  communicate  about 
issues  concerned  in  context;  2)  assess  and  manage  progresses,  gaps  and  risks;  and  3) 
consider  options  or  trade-offs. 

The  conceptualisation  based  on  the  categorisation  and  relationship  reference  models 
(Figure2  4  to  6)  of  military  SoS  enables  engineering  efforts  and  management  activities  to  be 
clearly  and  properly  planned,  organised  and  carried  out  for  specific  SoS  identified,  rather 
than  for  ad  hoc  definitions  of  scopes/ contexts  or  a  messy  collection  of  systems. 

Another  important  benefit  from  the  proposed  conceptualisation  practice  is  an  effective 
approach  to  exploring  and  designing  emergent  behaviours  and  joint  effects  based  on 
relevant  military  SoS  identified.  Many  important  operation  features  and  requirements  for 
joint  force  integration  or  integrated  capabilities  are  actually  delivered  or  presented  as 
positive  or  desirable  emergent  behaviours  and  joint  effects.  These  emergent  behaviours  are 
not  well  or  fully  designed  when  constituent  systems  or  SoS  are  designed  individually.  This 
proposed  conceptualisation  approach  enables  investigation  and  design  of  some  important 
joint  warfighting  functions,  such  as  C2,  battlespace  awareness,  joint  fires,  battlespace 
manoeuvre,  force  protection  and  logistics,  to  be  conducted  in  right  context,  that  is,  directly 
against  defined  sets  of  0_SoS  (or  M_SoS)  and  U_SoS  in  an  integrated  and  consistent 
manner  [Chen,  2016].  If  needed,  on  the  other  hand,  some  operation  conflicts  or 
uncertainties  can  be  examined  and  addressed  accordingly. 
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7.  SoS  Development  States  and  Transition  Paths 

Given  the  SoS  diversity  and  the  development  complexity  shown  in  Figure  1,  it  has  been  a 
difficult  question  for  SE  community  [Dahmann,  2008  and  2011]  how  SoS  are  created  or 
developed  or  whether  the  development  can  be  effectively  controlled  and  managed  and 
how.  Depending  on  progresses  and  outcomes  from  engineering  factors/ efforts  (i.e. 
planning,  design  and  development),  SoS  may  appear  in  very  different  development  states 
and  have  more  complicated  lifecycle  management  issues  than  a  traditional  system.  Each 
SoS  is  in  one  of  development  states  at  a  given  point  of  time  throughout  its  lifecycle.  From 
an  engineering  management  viewpoint,  these  development  states  can  be  characterised  as 
below: 


•  Envisaged  SoS  is  a  conceptual  description  of  SoS  to  enable  study,  analysis  and 
planning,  which  defines  at  a  high  level  the  constituent  systems  and  indicates  their 
roles,  relationships  and  interdependencies.  An  envisaged  SoS  in  any  category  is 
created  with  an  expectation  on  what  it  needs  to  deliver  and  how  it  might  do  so. 

•  Planned  SoS  is  a  SoS  context  defined  in  an  endorsed  agreement  or  plan  for  a 
central  purpose,  which  specifies  requirements  for  constituent  systems  or 
involvements  of  elements,  and  indirectly  specifies  responsibilities  of  relevant 
stakeholders.  This  context  is  used  as  an  agreement  for  verification,  systems 
development  and  capability  acquisition.  It  usually  defines  'what'  but  not  'how'.  A 
planned  SoS  means  the  assurance  and  requirements  for  the  SoS  to  be  achieved  at 
SCOTS  level  1,  or  potentially  SCOTS  level  2  or  even  SCOTS  level  3  if  the 
development  is  to  continue. 

•  Designed  SoS  is  a  design  with  technical  details  on  all  relations/ interdependencies 
and  interactions/ cooperation  between  constituents  or  their  elements,  and  is 
captured  in  models,  architecture  views  or  other  forms  of  specifications.  It  is  created 
for  validation,  development  and  implementation,  and  provides  details  on  'how  the 
SoS  operates  as  a  whole.  A  designed  SoS  can  be  achieved  at  SCOTS  level  2,  or 
SCOTS  level  3  if  the  development  is  completed  accordingly. 

•  Realised  SoS  is  a  real  world  SoS  that  has  all  its  constituent  systems  and 
components  available  and  brought  together.  Flow  a  SoS  is  realised  is  determined 
by  the  engineering  factor  or  its  development  state  transition  path  as  shown  in 
Figure  7. 

•  Deployed  SoS  is  a  specific  state  or  application  of  realised  military  SoS  in  exercises 
or  operations,  which  is  generated  through  campaign  planning  and  configuration.  A 
deployed  SoS  may  differ  from  the  realised  one  due  to  operation  needs  and 
flexibility  requirements  for  military  SoS.  The  closer  or  the  more  similar  (if  not 
same)  a  deployed  SoS  to  a  realised  SoS,  the  quicker,  more  efficient  and  more 
predictable  the  deployment. 
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Figure  7  Military  SoS  development  states  and  transitions 

The  lifecycle  of  a  SoS,  therefore,  starts  once  it  is  conceptually  defined  or  created,  resultant 
from  a  decision  of  planning,  study  or  design,  no  matter  whether  its  constituents  exist  or 
not.  This  lifecycle  continues  and  may  formally  involve  a  complete  or  ideal  development 
process  for  all  constituent  systems,  from  planning,  design,  development  to  realisation 
(becoming  a  real  world  SoS).  In  practice,  however,  lifecycles  of  some  SoS  may  go  through 
different  development  processes  or  skip  some  development  states  as  indicated  by  dot  lines 
in  Figure  7,  due  to  features  of  their  formations,  conditions  of  its  constituents  and  decisions 
from  the  engineering  factor.  As  indicated  in  Figure  7,  there  are  three  typical  state  transition 
paths. 

How  well  can  a  SoS  operate  as  a  whole?  If  using  the  characterisation  of  SCOTS  levels  to 
assess,  it  is  determined  by  how  the  design  and  development  is  conducted,  as  indicated  in 
Table  1,  including  both  what  was  designed  previously  for  individual  constituents  and 
what  was  done  to  the  SoS  as  a  whole.  If  a  SoS  is  targeted  for  a  particular  SCOTS  level,  its 
development  requirements  (state  transition  path)  and  engineering  products  required  are 
implicitly  defined  as  illustrated  in  Figure  7.  A  targeted  SCOTS  level  may  not  be  achieved  if 
there  are  significant  failures  in  development  or  improper  decisions  or  arrangement  along 
with  its  state  transition  path. 


An  important  issue  specifically  for  SoS  explicitly  explored  in  Figure  7  is  potential 
development  state  transition  paths  and  their  consequences  mapped  to  SCOTS  matrix.  This 
is  not  considered  in  the  typical  'V'  model  of  system  development  or  reflected  in  the  'wave 
model'  for  SoSE  [Dahmann,  2008].  A  development  state  transition  for  SoS  occurs  when 
certain  development  milestones  are  achieved  or  some  management  decisions  are  made. 
The  transitions  from  the  envisaged  or  the  planned  directly  to  the  realised  means  the  SoS  (if 
assume  it  was  not  previously  designed  to  a  certain  extent  before)  did  not  go  through 
proper  design  and  development  processes  for  the  SoS  as  a  whole.  This  situation  occurs  if 
all  constituent  systems  exist  or  available  after  acquisition,  and  are  brought  together. 
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without  adequate  engineering  efforts  made  in  design  and  integration.  Such  a  SoS,  as 
indicated  in  Figure  7,  is  most  likely  to  be  at  SCOTS  level  1. 

The  realisation  state  is  thus  resulted  from  either  the  completion  of  development  and 
integration  or  a  management  decision  for  implementation  of  a  new  arrangement  (based  on 
the  envisaged  or  the  planned)  of  the  constituents  that  already  exist.  A  realised  military 
SoS,  based  on  the  existing  conditions  of  development,  can  operate  in  training,  exercises  or 
real  operations  at  a  particular  SCOTS  level.  A  formal  announcement  of  the  realisation  for 
some  military  SoS,  such  as  a  warship,  is  made  through  a  certification  process,  in  which  a 
particular  SCOTS  level  (either  a  targeted  or  a  different  one)  can  be  confirmed  through 
adequate  assessments,  or  testing  &  evaluation  (T&E).  A  realised  SoS  does  not  have  to  be  in 
operation  all  the  time  or  all  its  constituents  must  'physically  stay  together'  as  a  whole, 
especially  for  0_SoS.  Once  a  SoS  is  realised,  it  remains  in  that  state  so  long  as  no 
significant  changes  to  conditions  and  statuses  of  its  constituents. 

SoS  in  different  categories  may  have  different  state  transition  conditions  and  paths  in 
practice.  Due  to  the  reality  and  requirements  of  concurrent  development  of  its 
constituents,  evolutionary  or  incremental  SoS  development  may  result  in  partial  state 
transitions,  which  no  doubt  further  increases  complexity  and  uncertainties,  and  is  required 
to  be  carefully  controlled  under  the  engineering  coordination  and  management  across 
constituent  systems  or  SoS. 

Force  planning  and  capability  development  processes  within  Defence  are  carried  out  to 
ensure  that  no  military  SoS  works  at  SCOTS  level  0.  Efforts  made  by  warfighters  before 
and  during  operations  ensue  all  military  systems  are  planned  adequately,  and  would 
operate  for  particular  mission  purposes  under  military  instructions  and  practice.  This  is 
usually  achieved  through  great  efforts  made  in  capability  development,  military  training 
and  force  preparation.  These  efforts  can  be  made  to  different  extents  with  different 
outcomes  in  terms  of  SCOTS  levels,  as  shown  in  Figure  7.  Depending  on  the  development 
conditions,  in  other  words,  a  SoS  could  possibly  work  at  different  SCOTS  levels  for 
defined  mission  purposes  or  operation  objectives.  It  means  it  operates  in  different  ways  or 
manners  with  very  different  performances  and  effects,  in  particular  in  aspects  of 
cooperation,  interoperability,  joint  effects,  emergent  behaviours  and  uncertainties. 

SoS  development  state  management  is  proposed  as  a  new  task  throughout  the  capability 
development  lifecycle.  The  part  of  the  task  is  to  raise  the  awareness  of  the  Defence 
community  that  adequate  attentions  should  be  paid  to  SoS  design  and  development  for 
SoS  in  all  those  categories  and  their  impact  to  operations.  The  development  state 
transitions  indicated  in  Figure  7  are  general  cases  with  common  features  and  their  most 
likely  resultant  outcomes  and  SCOTS  levels,  but  do  not  offer  detailed  descriptions  of  these 
transitions  for  various  SoS.  Given  the  development  complexity,  it  may  be  necessary  to 
further  develop  methods  and  solutions  for  SoS  assessments,  integration  management  or 
T&E,  in  order  to  achieve  effective  development  state  control  and  management  for  SoS  in 
different  categories. 

The  proposed  conceptualisation  to  a  SoS  problem  space  makes  the  development  state 
management  possible  and  be  directly  conducted  against  identified  SoS.  Some  specific 
issues  or  development  requirements  (in  models,  architectural  views  and  integration)  for 
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particular  SoS  categories  should  be  considered,  in  particular  in  association  with  defence 
processes  and  stakeholder  responsibilities.  For  example,  force  design,  capability  concept 
development,  force  generation  and  preparation  should  generate  design  products  or  be 
conducted  against  identified  0_SoS.  High  SoS  interdependencies  lead  to  a  need  of 
systematic  SoS  development  state  management  and  coordination  cross  SoS.  It  is  a  key  to 
the  success  of  concurrent  developments,  acquisitions  and  evolutions  across  multiple 
relevant  military  SoS  in  different  categories,  as  discussed  in  Section  9. 

The  targeted  SCOTS  level  and  expected  performance  (or  technical  status)  for  a  SoS  can  be 
achieved  only  if  it  is  delivered  through  the  adequate  state  transition  path  with  required 
engineering  products.  In  the  real  world  practice,  due  to  inadequate  identification  of  SoS 
and  the  development  histories,  it  is  possible  that  the  design  is  only  partially  achieved  for  a 
given  SoS.  This  is  likely  to  result  in  increased  uncertainty  for  the  technical  status,  as 
discussed  in  the  next  section,  and  high  complexity  for  development  management,  and 
consequently  increased  operation  difficulties,  in  fact  being  passed  onto  the  warfighters. 

Real  world  SoS  can  be  either  enduring  in  nature  or  only  exit  as  a  whole  when  in  exercises 
or  operations.  The  state  transitions  illustrated  in  Figure  7  have  been  drawn,  for  sake  of 
simplicity,  as  a  one-way  process.  In  reality,  due  to  the  need  of  evolution,  a  SoS  may  need 
to  repeat  some  development  activities  (further  completion  and  improvement  in  design)  in 
order  to  improve  its  design  and  technical  status  (based  on  feedbacks,  lessons  learnt, 
experimentation,  trials  and  exercises),  or  to  maintain  its  required  SCOTS  level  after  some 
component  systems  or  SoS  change. 

The  realisation  of  0_SoS,  such  as  achieving  the  readiness  for  amphibious  operations,  is  a 
very  complicated  process  and  can  take  a  long  time  if  it  has  high  requirements  for 
integration,  cooperation  and  interoperability.  It  may  have  difficulties  to  achieve  desired 
outcomes,  even  after  a  long  period  of  development,  if  relevant  SoS  involved  in  all 
categories  are  not  properly  designed  and  managed.  0_SoS  has  its  unique  features  in 
development  and  often  involves  an  iterative  process  from  planning  to  realisation,  in  order 
to  complete  and  improve  some  aspects  of  operation  design,  in  particular  in  human-related 
aspects,  such  as  C2  processes,  cooperation  and  interoperability.  Military  trials,  exercises 
and  trainings  conducted  to  test,  experience  and  improve  operations  should  be  considered 
as  a  part  of  design  and  development  process  for  0_SoS  and  U_SoS. 

The  deployed  SoS  is  a  special  state  of  military  SoS  after  realisation  when  they  are  in 
deployment,  which  can  be  either  same  or  different  from  the  realised  one  as  a  special 
requirement  for  military  SoS.  A  number  of  sets  of  0_SoS  are  produced  up  to  the  realised 
state  by  joint  efforts  in  force  generation,  training  or  campaign  planning.  In  the  process  of 
development,  these  0_SoS  are  used  as  shared  contexts  for  SoS  involved  in  other  categories 
to  be  planned,  designed  and  tested. 

Due  to  potential  different  outcomes  resultant  by  different  state  transition  paths.  Defence 
organisations  should  appreciate  and  pay  attention  to  difference  in  performance  and  joint 
effects  when  operating  at  different  SCOTS  levels  for  a  given  0_SoS.  In  particular,  note  the 
difference  in  integration  and  cooperation,  with  the  same  set  of  constituent  systems  or  SoS 
(that  is,  same  force  units,  platforms  and  capabilities).  In  the  joint  force  design,  it  is 
necessary  to  decide  and  specify  which  SCOTS  level  should  be  targeted  for  future 
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operations  (0_SoS),  which  indirectly  defines  integration  needs  (INs)  in  relevant  aspects. 
The  responsibility  for  0_SoS  design  is  shared  between  warfighters  and  capability 
developers,  as  discussed  in  Section  9. 

In  the  current  force  and  capability  development  without  using  SoS  thinking,  operations 
and  force  units/ elements  are  not  formally  identified  as  0_SoS  or  U_SoS.  Consequently, 
their  design  practice  is  usually  not  formally  established  and  conducted  with  defined 
design  products  (i.e.  models  or  architectural  views).  It  means,  as  indicated  in  Figure  7,  that 
many  0_SoS  or  U_SoS  could  not  operate  as  intended  or  wished  if  they  did  not  go  through 
the  state  of  the  designed  or  in  fact  transited  directly  from  the  planned  to  the  realised. 
Missing  or  incomplete  design  of  operations  (O-SoS)  and  force  elements  (U_SoS)  is 
considered  as  a  main  cause  to  many  problems  and  delays  of  joint  force  integration  and 
development  of  integrated  capabilities,  as  discussed  in  Section  9. 

For  the  best  interests  of  military  operations,  the  shorter  the  realisation  process  the  better,  in 
particular  for  an  0_SoS  at  a  given  targeted  SCOTS  level.  Is  it  possible  that  an  0_SoS  could 
be  quickly  realised  at  a  desired  SCOTS  level  (e.g.  SCOTS  level  2  or  above)  from  the 
planned  state  or  even  the  envisaged,  without  going  through  a  long  development  process? 
There  are  two  ways  to  help  achieve  such  a  goal: 

1.  Fully  designing,  developing  and  testing  a  number  of  reference  0_SoS  to,  or  close  to, 
their  realisation  through  force  design  and  generation,  and  make  them  as  close  as 
possible  to  potential  real  operations;  and 

2.  If  possible,  developing  adaptive  or  pre-designed  modular  components  of  SoS  in 
other  categories,  under  well-established  guidance  of  SoS  integration  and  cooperation 
patterns,  such  that  they  could  be  quickly  aggregated  and  'plug-in  and  play'  to  form 
different  0_SoS  as  needed. 

It  is  suggested  that  Defence  consider  a  well-designed  combination  of  these  two  ways  in 
force  and  capability  development. 

In  order  to  deliver  joint  force  and  integrated  capabilities.  Defence  should  consider  more 
rigorous  processes  of  SoS  design  and  clear  specifications  on  development  requirements  (in 
areas  such  as  integration  and  cooperation),  targeted  SCOTS  levels  and  required  design 
products  (i.e.  architecture  views  or  models),  according  to  Tables  1  an  3.  Introducing  the 
SoS  development  state  concepts  and  the  state  transition  diagram  enables  the  Defence  to 
consider  the  1st  order  assessment  of  military  SoS,  namely,  SoS  development  assessments, 
to  examine  its  development  history  and  how  it  has  come  to  as  a  SoS.  For  a  given  SoS  of 
interest  identified,  the  assessment  begins  with  examining  the  specification  of  a  targeted 
SCOTS  level  for  its  development.  Based  on  the  state  transition  diagram,  the  decision  on  the 
targeted  SCOTS  level  made  in  envisaging  or  planning,  to  a  certain  extent,  determines  the 
development  process  requirements  or  the  required  state  transition  path.  The  1st  order 
assessment  can  be  continuously  carried  out  throughout  development  stages  to  ensure 
relevant  development  activities  or  processes  to  be  timely  conducted  for  various  SoS  in 
different  categories  and  required  development  products /  artefacts  to  be  generated  in  right 
context. 
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The  information  on  SoS  development  states  and  its  transition  paths  should  be  recorded 
and  maintained  as  engineering  artefacts  since  it  shows  engineering  facts.  These  artefacts 
indicate  or  reflect  both  possible  outcomes  generated  and  potential  risks  or  gaps  that  have 
impacts  on  integration  or  interoperability  with  other  relevant  SoS  [Chen,  2015]. 
Understanding  of  SoS  development  states,  transition  paths  and  their  relations  to  progress 
and  quality  of  planning,  design  and  development  is  an  important  part  of  the 
understandings  of  lifecycles  of  SoS  and  their  specific  engineering  issues. 


8.  SoS  Technical  Statuses 

The  technical  status  is  a  complementary  concept  to  the  SoS  development  states  and  is 
introduced  to  examine  how  well  a  SoS  is  realised  and  how  well  it  can  operate  under  the 
influence  of  the  engineering  factor,  according  to  conditions  in  benchmarked  aspects 
defined  in  SCOTS  matrix  (Table  1).  It  is  only  considered  for  the  realised  or  the  deployed 
SoS  and  used  for  development  control  and  engineering  management,  assessments,  or  T&E. 
Different  engineering  efforts  and  outcomes  can  result  in  a  SoS  in  different  technical 
statues,  even  with  the  same  constituents.  A  SoS  may  typically  appear  in  the  following 
situations  in  terms  of  the  ability  to  function,  depending  on  different  levels  and 
completeness  of  engineering  efforts: 

•  Situation  A  (functional  'as  it  is')  where  the  constituents  exist  and  are  brought 
together,  but  are  not  previously  designed  and  developed  as  a  whole  -  consequently, 
it  may  operate  at  any  SCOTS  level.  In  a  case  at  a  lower  or  unsatisfied  SCOTS  level,  it 
generally  requires  extensive  intervention  by  the  operators  or  even  developers  to 
continue  or  redo  some  design  or  development  work  in  order  to  improve  its  technical 
status.  It  is  'ideal'  but  rare  if  a  SoS  could  operate  at  a  targeted  SCOTS  level  in  the 
Situation  A. 

•  Situation  B  (partly  functional  as  planned  and  designed)  where,  due  to  the 
evolutionary  development,  a  SoS  is  realised  but  integration  and  development  are 
only  partially  completed;  or  some  constituents  or  parts  of  the  SoS  do  not  function  as 
planned  or  designed  due  to  uncompleted  development  or  changes  -  this  will 
generally  deliver  a  SoS  that,  but,  is  unlikely  to  achieve  its  full  potential  as  expected 

•  Situation  C  (fully  functional  as  designed)  where  all  components  are  fully  planned, 
designed,  developed  and  integrated  to  achieve  its  targeted  SCOTS  level 

or 

•  Situation  D  (not  functional)  where,  despite  being  in  the  state  of  the  realised,  some 
constituents  are  not  available  due  to  some  reasons  (e.g.  in  processes  of  upgrading  or 
maintenance). 

Situations  A,  B  and  C  are  resulted  by  the  outcome  of  development  or  management 
decisions.  Difference  between  Situations  A  or  B  and  Situation  C  is  potential  gaps  between 
the  targeted  SCTOS  level  and  what  is  actually  realised.  If  there  is  no  design  requirement  or 
no  expectation  or  requirement  for  a  targeted  SCOTS  level,  there  will  be  no  difference 
between  Situation  A  and  Situation  C.  Situation  D  is  a  special  case  for  a  realised  SoS,  in 
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which  it  is  temporally  not  functional  or  not  available,  due  to  technical  failures  of  its  main 
constituents,  maintenance  needs  or  a  management  decision.  The  awareness  of  these 
situations  helps  stakeholders  effectively  plan  and  organise  V&V  and  T&E  activities  and 
assess  their  outcomes  accordingly. 

Thus,  the  examination  on  the  technical  status  of  a  SoS  can  be  considered  as  the  2nd  order 
assessment  (or  SoS  T&E)  from  a  viewpoint  combining  the  ability  to  function  (that  is,  4 
situations)  and  the  way  it  operates  (namely,  4  SCOTS  levels).  Key  stakeholders  and  SoSE 
teams  thus  need  to  consider  and  prepare  from  both  engineering  and  management 
viewpoints  how  to  deal  with  these  situations.  To  arrange  and  conduct  effective  T&E,  for 
example,  stakeholders  need  to  work  out  aspects,  focusses  and  schedules  of  T&E  for 
different  SoS  at  right  time. 

Specific  assessment  (as  part  of  the  2nd  order  assessment)  of  the  technical  status  for  military 
SoS  (SoS  T&E)  can  be  undertaken  in  particular  aspects,  such  as:  integration,  cooperation, 
emergent  behaviours  and  sustainability,  plus  some  specific  considerations  based  on 
different  categories  of  SoS.  In  practice,  appropriate  metrics  need  to  be  developed  and  the 
appropriate  information  should  be  captured  in  these  aspects  in  order  to  assess  the 
technical  status.  Assessments  of  the  realised  SoS  may  provide  useful  lessons  learnt,  but  are 
generally  too  late  to  provide  effective  feedback  to  the  development  of  the  SoS  and  its 
components.  Thus,  appropriate  indicators  and  proxies,  through  conducting  the  1st  order 
assessment  (including  some  T&E  efforts  for  constituents),  must  be  identified  as  early  as 
possible  in  the  earlier  development  stages  if  more  timely  feedback  can  be  provided  to 
ensure  delivery  of  SoS  at  a  targeted  SCOTS  level.  This  is  extremely  important  for  the 
situation  involving  multiple  SoS  in  different  categories,  due  to  their  interdependencies. 

Specifications  on  targeted  SCOTS  levels  with  development  requirements  for  military  SoS 
in  different  categories,  as  suggested  in  the  last  section,  can  effectively  shape  the  up-front 
design  specifications  for  SoS  and  their  constituents,  in  particular  in  areas  such  as 
integration,  cooperation  and  interoperability  requirements.  This  means  the  technical  status 
assessment  of  a  SoS  can  be  partly  assessed  through  examining  the  development  state,  the 
state  transition  path  and  quality  of  design  and  development  (i.e.  models  and 
architectures),  as  part  of  the  1st  order  assessment,  against  a  targeted  SCOTS  level. 

Another  important  aspect  of  SoS  complexity  related  to  the  technical  status  of  a  SoS,  which 
is  worth  to  point  out  specifically,  is  the  disorder  (the  worst  case  is  a  chaos)  in  SoS 
operation,  namely  the  4th  column  in  the  SCOTS  matrix.  It  is  mainly  contributed  by 
uncertainties  and  disagreements  [Stacey,  2000]  between  its  constituents  and  associated 
with  relationships  between  them.  One  of  main  purposes  or  outcomes  of  planning  and 
development  of  SoS  is  in  fact  to  reduce  or  minimise  uncertainties  and  disagreements  to 
ensure  achieving  a  targeted  SCOTS  level,  through  conducting  various  design  and 
development  activities.  As  shown  in  Figure  7,  the  more  systematic  and  more  complete  the 
development  process  (or  the  transition  path)  the  better  the  technical  status  can  be  possibly 
achieved. 

The  technical  status  of  SoS  is  thus  development  condition-based  operation  features  in 
cooperation  and  interoperability  resultant  by  the  engineering  factor.  After  being  realised, 
the  technical  status  of  a  SoS  still  can  possibly  change  from  one  situation  to  another,  even 
sometime  without  involving  formal  changes  of  its  development  state.  Thus,  it  is  the  task  of 
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SoSE  teams  or  relevant  stakeholders  to  effectively  monitor  and  manage  the  technical 
statuses  throughout  their  lifecycles. 

SoS  can  change  from  one  SCOTS  level  to  another  when  certain  management  conditions 
change  or  development  progresses  are  achieved.  The  technical  status  of  a  given  SoS  can  be 
improved  if  appropriate  development  is  carried  out  or  certain  management  decisions  for 
more  effective  cooperation  are  made.  Of  course,  it  could  also  change  undesirably  if  quality 
and  conditions  of  elements  involvements  and  relationships  change  or  are  not  maintained. 
In  general,  some  quality  features  of  a  SoS  may  change  if  it  changes  from  one  SCOTS  level 
to  another,  as  illustrated  in  Figure  8.  Thus,  no  design  or  no  management  of  SoS  means  no 
assurance  for  the  technical  status,  as  indicated  in  Figures  7and  8. 

SCOTS  Levels 
SCOTS  level  0 
SCOTS  level  1 
SCOTS  level  2 
SCOTS  level  3 

Low" 

Figure  8  Quality  features  change  at  different  SCOTS  levels 

Technical  status  assessment  and  management  of  SoS  (including  SoS  integration 
assessment)  is  important  but  has  been  difficult,  largely  due  to  missing  effective 
identification  of  SoS  and  lacking  adequate  measures  for  development  management.  SoS 
thinking  offers  a  good  foundation  for  considering  and  developing  methods  and  metrics  for 
SoS  technical  status  assessment  and  management.  Based  on  the  SoS  thinking,  a  given  SoS 
can  be  identified  and  assessed  accordingly  in  terms  of  its  development  states,  technical 
statuses,  and  gaps  to  a  targeted  SCOTS  level  through  conducting  both  the  1st  order 
assessment  and  the  2nd  order  assessment.  More  detailed  discussions  on  concepts  and 
methods  for  SoS  assessments  will  be  reported  in  a  separate  report.  The  assessment  for 
different  SoS  can  be  conducted  as  parts  of  various  processes  of  evaluation,  testing  or 
certification  by  relevant  stakeholders  within  Defence. 
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9.  SoS  Design  Relevance  and  Paradigm 

SoS  design  is  a  key  part  of  the  iterative  process  of  SoSE  suggested  by  [Dahmann,  2008] 
[DoD,  2008]  as  illustrated  in  Figure  1,  but  becomes  very  complicated  and  unclear  while 
facing  a  SoS  problem  space  in  Defence,  because  of  issues  associated  with  various  SoS  in 
those  categories  and  their  interdependencies.  It  remains  as  a  question  to  be  addressed 
what  SoS  design  is  about  or  how  it  can  be  undertaken  adequately  and  effectively  for 
multiple  SoS  in  different  categories.  It  is  not  clearly  described  and  discussed  by  either  SoS 
architecting  principles  for  a  single  SoS  or  architecture  development  guidance  from  many 
existing  architecture  frameworks  or  engineering  methodologies. 
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Without  a  good  practice  of  the  conceptualisation  based  on  the  SoS  categorisation,  ad  hoc 
development  of  various  models  or  architectures  in  a  SoS  problem  space  may  serve 
purposes  of  individual  activities  to  a  certain  extent.  However,  it  may  create  confusion  or 
additional  complexity  for  development  of  other  systems  or  SoS  (even  using  architectural 
frameworks).  It  is  because  they  may  not  be  developed  with  full  considerations  of 
relationships  and  interdependencies  to  other  relevant  SoS.  Each  category  of  SoS,  because 
of  its  features,  not  only  requires  its  designers  to  achieve  its  own  specific  design  objectives 
and  outcomes  (as  indicated  in  Table  3),  but  also  has  its  own  design  context  or 
environment.  The  design  activity  should  be  coordinated  accordingly  with  activities  for 
other  relevant  SoS  in  the  SoS  problem  space. 

It  is  important  to  remember  the  difference  between  a  large  complex  system  and  SoS  in 
design.  The  design  for  each  SoS,  if  conducted,  should  be  focussed  on  cooperation  and 
integration  between  its  constituents,  rather  than  designing  their  individual  functions  and 
architectures.  The  SoS  thinking  considerations  in  the  categorisation,  development  states 
and  interdependencies  between  different  SoS  can  provide  better  definitions  or  exploration 
for  SoS  design  activities  and  their  outcomes  in  a  joint  manner.  Design  activities  for  SoS  in 
different  categories  need  to  be  organised,  carried  out  and  coordinated  in  an  integrated 
design  paradigm,  as  illustrated  in  Figure  9. 


Force  Level  Design 
(Structure  &  Operations) 

SoS  Development 
&  Acquisition 

Capability  and  System 
Development  &  Acquisition 
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Force  Generation  S  Preparedness 
(Integration,  Implementation  and 
TSE  of  SoS  in  all  categories  ) 
(Realised  SoS  in  all  categories) 


:  SoS  design  is  generated;  SoS  design  is  used;  SoS  designs  are  interdependent. 


Figure  9  Military  SoS  design  paradigm 

The  design  of  military  SoS  should  be  conducted  in  a  collaborative  and  responsive  practice, 
which  involves  multiple  stakeholders  from  strategic  planners,  war-fighters,  capability 
planners,  capability  analysts  and  designers  of  systems  and  capabilities.  There  are  two 
main  collections  of  SoS  design  products  as  shown  in  the  middle  of  Figure  9.  One  contains 
design  products  (models  and  architectures)  of  0_SoS  and  U_SoS.  The  other  includes 
design  products  of  C_SoS,  P_SoS  and  I_SoS.  Current  main  design  or  architectural  activities 
and  traditional  SE  practice  are  mainly  conducted  for  design  products  of  C_SoS,  P_SoS  and 
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I_SoS.  Due  to  the  missing  identification  of  0_SoS  and  U_SoS,  their  design  products  are 
currently  either  not  formally  generated  or  only  partially  produced  in  ad  hoc  manners  in  a 
mixture  with  the  products  for  C-SoS,  P_SoS  and  I_SoS. 

There  are  two  main  reasons  to  separate  them  in  the  two  collections  in  the  paradigm.  First, 
they  are  generated  in  very  different  processes  or  activities  by  different  stakeholders. 
Design  products  for  C_SoS,  P_SoS  and  I_SoS  are  mainly  generated  from  one  of  four 
process  boxes  in  Figure  9,  that  is,  in  capability  and  systems  development  and  acquisition 
by  architects,  systems  engineers  and  integrators.  Design  products  for  0_SoS  and  U_SoS 
are  produced  very  differently,  as  illustrated,  in  fact  from  three  different  process  boxes  (as 
indicated  by  red  arrows  in  Figure  9)  for  different  aspects  respectively  by  mainly  force 
planners  and  warfighters.  Secondly,  the  interdependencies  or  relevance  between  design 
products  in  these  two  collections  are  important,  but  are  currently  ignored  or  unaddressed 
in  the  current  practice.  As  observed,  missing,  incomplete  or  inconsistent  development  or 
designs  of  0_SoS  and  U_SoS  often  cause  significant  problems  for  development  and 
acquisition  of  C_SoS,  P_SoS  and  I_SoS.  These  problems  appear  not  only  in  areas  of 
integration,  interoperability,  agility,  design  for  changes  and  standards,  but  also  for  those 
important  emergent  behaviours  such  as  C2,  joint  fires  and  battlespace  awareness. 

There  are  many  important  issues  in  SoS  design  for  military  SoS  in  different  categories 
(which  will  be  discussed  in  a  separate  report).  For  examples,  there  are  some  specific  issues 
related  to  0_SoS,  briefly  discussed  as  below: 

•  0_SoS  design  should  be  undertaken  by  appropriate  stakeholders.  It  needs  to  cover 
a  number  of  important  aspects,  including  mission  CONOPS,  mission  objectives 
(MOE  and  MOP),  aggregation  requirements  of  constituents  and  participating 
elements,  processes  (C2)  and  information  models,  joint  functions,  logistics  and 
other  emergent  behaviours.  0_SoS  design  should  starts  from  force  design  and 
continuously  to  be  carried  out  to  force  generation  and  preparedness. 

•  V&V  activities  for  0_SoS  by  relevant  stakeholders  need  to  examine  issues  of 
relevance,  integration  and  coordination  between  or  crossing  all  constituent  SoS  and 
their  designs.  These  activities  can  be  carried  out  in  relevant  processes  or  activities 
for  the  constituents  as  needed,  in  a  similar  manner  as  described  by  'Wave  Model' 
in  [Dahmann,  2008] . 

•  Some  aspects  of  design  for  C_SoS,  I_SoS  or  P_SoS  in  relation  to  cooperation  and 
integration,  such  as  joint  fires,  should  be  based  on  relevant  aspects  of  designs  of 
relevant  and  commonly  shared  0_SoS  (potentially  crossing  a  set  of  0_SoS).  In 
order  to  be  able  to  play  their  potential  roles  in  different  operations,  functions  and 
CONOPS  of  individual  systems  and  capabilities  should  be  designed  to  meet 
requirements  of  planned  operations  and  fit  to  all  their  operation  contexts  and 
environments. 

•  An  adequately  defined  set  of  relevant  0_SoS  can  be  viewed  as  a  mission  space  for  a 
specific  domain  (such  as  Amphibious).  The  defined  sets  of  0_SoS  for  different 
domains  can  jointly  present  a  shared  defence  mission  space,  that  is,  a  uniform 
conceptualisation  and  contextualisation  to  defence  operation  needs,  as  a  core  part 
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of  force  design.  (This  topic  will  be  further  explored  and  discussed  in  a  separate 
report.) 

In  addition  to  considering  the  architecting  principles  for  a  single  SoS  [Marie,  1998],  the 
design  of  0_SoS  is  a  complicated  process  involving  multiple  design  activities,  starting 
from  the  force  level  design  and  being  continuously  carried  out  to  processes  of  force 
generation,  and  preparedness,  in  order  to  cover  all  aspects  of  operations.  These  designs  of 
0_SoS  are  used  (as  indicated  by  yellow  arrows)  for  various  purposes  from  planning, 
analysis,  training,  development  agreements  to  references  for  V&V  or  T&E  of  relevant  SoS 
in  other  categories.  Thus,  relevant  military  SoS  should  be  designed,  developed  and 
evaluated  in  an  integrated  and  coordinated  manner  as  shown  in  Figure  9,  rather  than  in 
isolation  or  based  on  assumptions  with  a  high  level  of  uncertainty. 

In  order  to  achieve  expected  outcomes  or  effects,  especially  for  joint  force  operations, 
selected  0_SoS  (or  M_SoS)  need  to  be  further  explored  in  a  number  of  aspects  at  either  the 
stage  to  be  envisaged  or  the  stage  to  be  designed.  These  aspects  are  not  usually  well 
covered  by  either  traditional  SE  or  Operations  Research  (OR)  /  operations  analysis  (OA), 
such  as: 

•  Confirmation  of  the  endorsement  by  relevant  stakeholders  to  this  context  (0_SoS) 
if  required 

•  Relations  to  task  lists  (addressed  in  the  combination  with  designs  of  relevant 
U_SoS) 

•  Relations  to  warfare  concepts,  mission  areas  or  mission  threads 

•  Relations  to  C2  arrangements  (addressed  in  the  combination  with  U_SoS  involved 
and  supporting  I_SoS) 

•  Relations  to  force  and  capability  design  or  SoS  in  other  categories 

•  Design  processes  and  requirements  produced  in  the  current  practice 

•  Integration  requirements 

•  Characterising  operation  features  as  they  work  at  different  SCOTS  levels  and  main 
potential  risks  or  gaps  to  achieve  the  targeted  SCOTS  level 

•  Management  and  engineering  focusses  (such  as  model/ architecture  management, 
development  state  transition  management  and  certification  process)  for  0_SoS. 

Ultimate  goals  for  defence  force  and  capability  development  are  their  successes  in 
operations  (i.e.  the  success  of  0_SoS).  Many  existing  development  methodologies,  such  as 
platform-based  or  capability-based  planning  and  development  focussing  on  I_SoS,  P_SoS 
or  C_SoS,  should  be  examined  in  terms  of  scopes  and  limits  in  the  design.  Defence  needs 
to  pay  specific  attentions  to  the  relevance  to  and  the  gaps  or  inconsistency  in  design  and 
development  of  0_SoS  and  U_SoS,  in  particular  in  order  to  achieve  joint  force  integration. 

The  high  complexity  and  complicated  interdependencies  between  designs  (or  architecture 
and  models)  of  relevant  SoS  in  different  categories  make  design  and  architecture 
management  a  key  to  success  of  the  whole  SoS  design  practice  [Chen,  2013a].  Individual 
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development  tasks  or  projects  work  as  parts  in  this  paradigm  and  make  their  contributions 
to  the  design  of  SoS  and  the  body  of  knowledge  of  military  SoS.  The  completeness  of 
designs  and  coherence,  consistency,  relevance  and  traceability  between  design  products 
(i.e.  models  or  architectures)  must  be  ensured  and  maintained  for  success  of  SoS 
integration  and  evolution.  Design  activities  of  individual  SoS  in  projects  or  tasks  can 
greatly  benefit  from  successful  SoS  design  management  not  only  in  costs  and  productivity 
but  also  more  importantly  in  quality.  It  is  the  SoS  design  management  (which  is  one  of 
main  tasks  of  SoSE)  that  can  provide  consistent  and  adequate  solutions  for  context 
management,  relationship  management,  development  state  management  and  integration 
management. 

Accountability  has  been  considered  as  a  critical  issue  for  force  and  capability 
development.  However,  it  is  difficult  to  address  due  to  lacking  effective  guidance  or 
methods  to  articulate  responsibilities  of  stakeholders,  and  to  assess  outcomes  or  products 
of  their  work  and  activities.  The  categorisation-based  SoS  design  paradigm  offers  a  context 
to  define  responsibilities  of  relevant  stakeholders  in  design  and  integration  of  SoS,  as 
illustrated  in  Figure  10.  It  can  also  be  used  as  a  basis  to  define  or  specify  relevant  design 
products  (i.e.  architecture  views  and  models,  as  indicated  in  Table  3)  of  various  SoS  and 
issues  of  SoS  interdependencies  and  relationships.  In  particular,  accountabilities  of 
stakeholders  in  addressing  interdependencies  between  SoS  for  required  integration  and 
interoperability  can  be  defined  and  monitored  in  a  clear  engineering  context  for  SoS 
identified  (as  discussed  in  Section  12),  after  consistent  conceptualisation  and 
contextualisation. 
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Figure  10  Responsibility  and  accountability  in  military  SoS  design  paradigm 

The  exploration  and  discussions  on  the  categorisation,  development  states  and  design 
paradigm  of  military  SoS  provide  a  better  understanding  and  context  setting  for  defence 
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organisations  to  review  and  improve  processes  and  practices.  The  rationalisation  and 
improvements  can  be  considered  not  only  for  capability  planning  and  acquisition  but  also 
in  force  planning,  design  and  generation,  in  order  to  ensure  all  SoS  in  different  categories 
to  be  properly  planned  and  designed  for  targeted  SCOTS  levels,  if  a  governance 
framework  can  be  systematically  established. 


10.  Extended  Community  of  Practice  (CoP)  for  SoSE 

and  SoS  Activities 


A  CoP  is  a  group  of  people  who  share  a  craft  and/or  a  profession,  who  can  evolve 
naturally  because  of  the  members'  common  interest  in  a  particular  domain  or  area 
[Wenger,  1998].  It  is  through  the  process  of  sharing  information,  knowledge  and 
experience  that  the  members  can  learn  from  each  other,  and  work  jointly  and  effectively  in 
a  shared  knowledge  environment. 

It  is  true  that  every  project,  every  activity  or  every  practitioner  has  specific  focuses  and 
scopes  for  their  work.  Why  is  SoS  thinking  needed?  While  facing  a  SoS  problem  space, 
efficiency,  effectiveness  or  success  of  their  works  is  highly  dependent  on  what  and  how 
other  people  do  in  their  works  due  to  high  interdependencies  between  systems  or  SoS.  Ad 
hoc  conceptualisation  and  inadequate  specifications  and  management  of 
interdependencies  would  result  in  serious  problems  and  difficulties,  and  even  further 
increase  unwanted  complexity  for  engineering  and  management.  A  consistent  thinking 
approach  becomes  important  and  is  needed  to  help  various  SoS  activities  arrive  at  a  shared 
understanding  and  consistent  conceptualisation  through  using  a  common  practice  and  a 
common  language  (that  is,  a  set  of  terminology  and  concepts  about  SoS). 

There  are  various  SoS  activities  that  all  have  roles  to  play  or  somehow  contribute  to  SoS 
success,  as  shown  in  Figure  11.  Many  proposed  SoS  methodologies  or  practices  are  often 
only  focused  on  traditional  areas  of  development  for  some  systems  or  SoS.  Through 
introducing  the  categorization,  SoS  thinking  helps  more  stakeholders  be  aware  of  being 
part  of  the  SoS  community.  This  SoS  stakeholders  community,  in  addition  to  the 
traditional  one  involved  in  SE,  also  involves  warfighters,  planners,  analysts,  project 
managers,  capability  managers  and  decision  makers  at  various  levels.  They  all  need  to 
understand  their  roles  and  responsibilities  for  SoS  success.  The  community,  based  on  a 
shared  thinking  strategy  and  a  common  language,  can  effectively  communicate  about 
military  SoS. 

High  complexity  of  SoSE  practice  and  activities,  which  is  hidden  in  the  SoS  process  model 
(Figure  1),  is  now  explored  from  different  perspectives  of  SoS  thinking.  This  complexity 
makes  the  SoS  CoP  perspective  become  more  critical  to  SoS  success,  which  requires 
stakeholders  (not  only  SoSE  teams  but  also  other  stakeholders)  and  SoS  activities  to  work 
very  differently  from  the  past  in  the  following  aspects: 

•  being  aware  of  their  responsibilities  in  SoS  design,  development,  management  and 
operation 
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•  being  aware  of  multiple  SoS  perspectives  and  worldviews  of  different  stakeholders 

•  sharing  a  common  body  of  knowledge  of  SoS  understandings  and  architectures 

•  using  a  consistent  approach  and  language  in  conceptualising  and  communicating 
about  SoS 

•  planning,  studying  and  developing  SoS  in  appropriate  contexts  in  coherence  with 
relevant  SoS  and  SoS  activities 

•  presenting,  assessing,  testing  and  managing  work  outcomes  of  SoS  activities  in 
appropriate  contexts  as  part  of  SoS  body  of  knowledge 

•  capturing,  controlling  and  managing  uncertainties  and  disagreements  to  reduce  or 
minimize  disorder  in  planning  and  development  (avoiding  chaotic  development) 

•  being  more  responsive  and  collaborative  to  changes,  impact,  uncertainties  and 
disagreements,  and  acting  timely  and  coherently 

•  increasing  coordination,  communications  and  knowledge  sharing  to  avoid 
duplications  and  incorrect  definitions  and  specifications  of  SoS. 


Figure  11  Variety  of  SoS  activities 

This  extended  SoS  CoP  requires  both  the  organizational  learning  and  knowledge  sharing 
to  be  achieved  through  and  featured  by  a  structurally  established  body  of  knowledge  of 
military  SoS,  rather  than  a  document-based  practice  or  solutions.  In  order  to  facilitate  and 
achieve  such  a  SoS  CoP  for  defence  organizations,  two  important  practice  enablers  are 
required:  1)  the  SoS  thinking  considered  and  applied  as  part  of  organizational  thinking, 
processes  and  practice;  and  2)  an  adequate  SoSE  practice  supporting  environment  created 
and  used  to  enable  SoS  design  management  and  facilitate  SoS  activities  and  collaboration 
[Chen,  2007]  [Chen,  2013a], 
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The  core  part  of  the  SoS  CoP  is  a  designed  SoSE  practice  covering  all  development  states 
or  stages  of  lifecycles,  with  a  number  of  processes  (or  sub-practices)  for  SoS  in  different 
categories  or  different  development  activities.  SoS  thinking  can  be  used  to  support  the 
design  and  tailoring  of  such  SoSE  practice,  and  to  develop  methods  and  metrics 
addressing  specific  SoS  issues,  requirements  and  complexity  in  those  perspectives.  (A 
separate  report  is  planned  to  discuss  in  details  on  a  designed  SoSE  practice  for  Defence.) 


11.  SoS  Thinking  Approach 

These  SoS  thinking  perspectives  are  specifically  introduced  to  tackle  common  problems 
and  difficult  issues  in  engineering  practice  for  SoS.  The  categorisation  and  relationship 
reference  models  of  military  SoS  together  offer  an  approach  to  conceptualising  a  military 
SoS  problem  space.  Such  a  practice  enables  engineering  efforts  and  management  activities 
to  be  more  clearly  and  effectively  planned,  organised  and  carried  out  for  the  SoS  of  interest 
identified  in  a  conceptualised  and  contextualised  SoS  problem  space.  In  particular,  SoS 
thinking  is  introduced  to: 

•  emphasize  the  importance  of  both  understanding  SoS  problems  from  multiple 
perspectives,  and  developing  adequate  concepts,  methods,  solutions  and  metrics 
based  on  those  perspectives; 

•  help  SoS  researchers  and  practitioners  to  first  get  SoS  conceptualisation  and 
contextualisation  right,  and  understand  the  SoS  complexity  in  a  SoS  problem  space; 

•  offer  an  appropriate  language  for  effective  discussions  and  communications  on 
various  issues  of  SoS,  which  is  currently  missing  but  important  for  achieving  a 
good  and  shared  understanding  of  SoS; 

•  encourage  and  facilitate  effective  communications  common  issues  in  appropriate 
contexts,  sharing  of  knowledge  and  coordination  across  areas,  stakeholders  and 
SoS  activities; 

•  help  organisations  or  projects  to  clearly  identify  SoS  of  interest  and  requirements  of 
SoSE  practice,  and  then  to  design  or  tailor  a  suitable  SoSE  practice;  and 

•  facilitate  consideration,  analysis  and  management  of  various  engineering  issues 
(such  as  SoS  assessment  and  integration  management)  across  life-cycles  of  multiple 
and  relevant  SoS  involved. 

To  help  understand  and  communicate  about  various  engineering  issues,  SoS  thinking 
perspectives  discussed  in  Sections  4  to  10  can  serve  as  a  set  of  complexity  lenses,  as  shown 
in  Figure  12,  to  jointly  explore  and  deal  with  high  complexity  of  a  SoS  problem  space.  The 
conceptualisation  and  contextualisation  achieved  through  using  SoS  thinking  can  help 
effectively  deal  with  and  control  complexity  of  SoS  development  and  management. 

Based  on  this  set  of  the  lenses,  it  is  proposed  that  SoS  thinking  can  be  applied  as  a  7-step- 
based  process  or  method,  as  shown  in  Figure  13,  to  help  stakeholders  and  SoS  activities 
effectively  communicate  about  SoS  and  systematically  establish  understandings  of  SoS 
problems  they  are  facing. 
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As  shown  in  Table  4,  at  each  step  through  asking  and  answering  the  those  questions, 
relevant  SoS  lenses  or  SoS  thinking  methods  are  used  to  help  analyse  and  examine 
relevant  issues.  This  process  can  effectively  lead  to  much  needed  conceptualisation  and 
contextualisation  in  a  SoS  problem  space.  The  SoS  thinking  approach  is  thus  a  process  of 
conceptualising  with  theory.  After  going  through  these  7  steps,  stakeholders  and  SoS 
activities  should  be  able  to  achieve  an  improved  understanding  of  given  SoS  problems. 


Figure  12  SoS  thinking  complexity  lenses 


SoS  Thinking  Approach 


SI:  Identify  &  understand 
SoS  Problems 


S2:  Identify  all  SoS  and  their  stakeholders  with  their 
responsibilities,  and  specify  targeted  SCOTS  levels 

S3:  Identify  and  specify  constituent  systems/SoS 
_ and  relationships  between  SoS _ 


S4:  Identify  and  specify  current  development  states 
_ of  SoS  and  their  state  transition  paths _ 


S5:  Assess  the  current  technical  _ 

statuses  of  relevant  SoS  if  already  realised 

S6:  Specify  development  requirements  and  identify 
development  gaps  for  targeted  SCOTS  levels 


S7  :  Identify  and  specify  objectives,  tasks,  products 
&  outcomes  of  SoS  activities 


Figure  13  7  Step-based  SoS  thinking  approach 

The  process  can  be  repeated  to  update  information  and  understanding  of  relevant  SoS  as 
the  problem  space  changes  or  evolves.  Through  such  an  iterative  process,  a  SoS  problem 
space  can  be  maintained  and  managed  as  a  set  of  SoS  identified  with  specified 
interdependencies,  rather  than  becoming  a  messy  collection  of  systems.  In  addition  to 
support  generation  of  specific  outcomes  to  underpin  planning,  analysis,  design  and 


36 


UNCLASSIFIED 


UNCLASSIFIED 


DST-Group-TR-3271 


development,  SoS  thinking  has  the  potential  to  encourage  individual  SoS  activities  to  work 
together  as  part  of  the  SoSE  practice  and  commonly  pay  attention  to: 

•  SoS  identification  and  specifications  (including  constituent  systems  or  SoS,  targeted 
SoS  types,  and  expected  state  transition  paths) 

•  interdependencies  between  SoS  identified 

•  Stakeholder  identifications  and  coordination 

•  Development  state  control  and  transition  management 

•  Technical  status  control  and  assessments 

•  SoS  design  coordination  and  management  (including  model  and  architecture 
management) 

•  SoS  integration  and  evolution  management 

•  SoS  complexity  management  in  relation  to  diversity,  relationships,  context, 
development  states  and  technical  statuses. 

Table  4  Descriptions  of  SoS  thinking  approach. 


Step 

SoS  thinking 

Methods 

Main  questions  to  answer 

Outcomes 

SI 

■  SoS  problem  space  case  analysis 

■  Which  case  of  SoS  problem  spaces  you  are  in? 

■  Confirming  SoS  problems&  eng,  factors 

S2 

■  SoS  identification  using  SoS 
categorisation 

■  SCOTS  matrix 

■  Which  SoS  are  you  facing  or  interested  (SoSI)? 

■  Which  stakeholders  are  concerned  or 
associated  with  SoS  identified? 

■  What  SCOTS  levels  should  they  be  targeted  at? 

■  A  SoS  list  and  a  set  of  SoS  IDC 

■  Specification  of  their  targeted  SCOTS 
levels 

■  Specification  of  stakeholders  concerned 
and  their  responsibilities 

S3 

■  SoS  relationship  reference  models 

■  Engineering  context  management 
schema 

■  How  are  these  SoS  related  each  other? 

■  How  should  these  relationships  between  SoS 
be  modelled  and  managed? 

■  Understanding  and  specifications  of 
relationships  in  SoS  IDCs 

■  Engineering  context  management 

S4 

■  SoS  development  states 

■  State  transition  paths 

■  SoS  design  relevance  and 
paradigm; 

■  Category-based  design  guidance 

■  What  development  states  are  they  in  and  what 
transition  paths  they  went  through? 

■What  design  products  have  been  generated? 

■  What  design  products  are  required  but  yet 
developed? 

■  Understanding  of  situations  of  SoS 
development 

■  Accesses  to  models  or  architecture 

■  Understanding  of  current  problems  of 
development 

S5 

■  SoS  technical  status  analysis 

■  SoS  design  and  development 
assessments 

■  What  technical  statuses  are  they  likely  to  be? 

■  What  development  gaps  exist  in  association 
with  these  SoS? 

■  Assessments  of  design  products 
required  and  their  availability  and  quality; 

■  Notices  and  requests  to  relevant 
stakeholders 

S6 

■  SoS  technical  status  assessments 

■  SoS  design  and  development 
assessments 

■  what  are  development  requirements  for  SoSI  if 
they  are  already  realised? 

■  Expectation  and  specifications  on  the 
quality  of  technical  status  or  the  targeted 
SCOTS  level  of  SoSI 

S7 

■  Category-based  design  guidance 

■  SoS  design  relevance  and 
paradigm 

■  Engineering  context  management 
schema 

■  Which  design  products  are  required  and  will  be 
generated  and  for  which  SoS? 

■  Which  are  main  problems  or  risks  facing  this 
activity? 

■  Understanding  of  development  gaps 
between  the  current  development  states 
of  SoS  and  the  design  required  for 
targeted  SCOTS  levels; 

■  Well-defined  purposes  of  activity 
outcomes 
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12.  Applications  of  SoS  Thinking 

The  value  of  SoS  thinking  can  be  realised  only  through  its  applications  by  the  SoS 
community.  The  SoS  thinking  process  is  complementary  to  systems  engineering  practice, 
rather  than  a  replacement,  and  can  be  considered  and  used  as  a  component  of  architecture 
frameworks  or  engineering  practice.  SoS  thinking  is  an  innovative  approach  and  new 
skills  to  be  used  to  support  SoS-related  activities,  rather  than  extra  overheads  or  additional 
workloads  for  development  or  management.  It  is  a  useful  activity  to  be  conducted  as  part 
of  many  SoS-related  activities,  such  capability  analysis,  scoping  studies,  architecture 
development,  systems/ integration  analysis  and  assessments,  and  project/program 
management.  A  summary  of  direct  benefits  and  difference  resulted  from  applying  SoS 
thinking  to  a  SoS  problem  space  is  given  in  Figure  14. 


•Before  applying  SoS  thinking 

□  Limited  shared  awareness  of  the  SoS  problem  space; 

□  Ad  hoc  identification  and  consideration  of  SoS 
concerned; 

□  No  effective  enabler  in  context  management  for 
effective  communications  and  engineering  management; 

□  No  consideration  on  diversity  of  military  SoS  and  their 
different  features  in  formation,  development  and 
management; 

□  Ad  hoc  or  inconsistent  specifications  and  management  of 
SoS  relationships; 

□  No  or  limited  consideration  on  SoS  development  states 
and  state  transition  paths; 

□  No  consideration  on  technical  status  management; 

□  No  adequate  metrics  and  method  for  SoS  assessments; 

□  Difficult  to  effectively  orchestrate  SoS  activities,  and 
relate  and  manage  relevant  outcomes;  and 

□  No  effective  and  systematic  solution  for  engineering 
artefacts  management. 


•  After  applying  SoS  thinking 

□  A  share  understanding  of  the  SoS  problem  space; 

□  Multiple  SoS  of  interest  and  concerned  are  identified 
consistently,  according  the  defined  categories; 

□  Key  relevant  stakeholders  can  be  identified  for  their 
responsibilities; 

□  Development  requirements  for  different  SoS  can  be 
specified  against  their  categories; 

□  Engineering  context  can  be  effectively  established  and 
managed  for  SoS  identified  and  handled  consistently 
across  SoS; 

□  Important  relationships  between  SoS  can  be  captured  and 
their  development  or  integration  requirements  can  be 
specified  accordingly; 

□  Development  states  and  transition  paths  of  SoS  identified 
can  be  effectively  planned  and  examined; 

□  SoS  assessments  can  conducted  from  both  perspective  of 
development  and  technical  statu;  ands 

□  Engineering  artefacts  management  can  be  supported  by  an 
engineering  context  management  schema;  and 


Figure  14  Difference  resulted  from  applying  SoS  thinking. 


The  application  of  the  SoS  thinking  approach  with  the  associated  methods  and  metrics  can 
bring  great  benefits  to  not  only  SoS  activities  but  also  organisations  in  a  long  run.  One  of 
these  benefits,  for  example,  is  the  effective  management  of  engineering  artefacts  generated 
in  planning,  development  and  management,  which  are  important  information  or 
knowledge  assets.  A  broad  range  of  engineering  artefacts  [Dahmann,  2010]  created,  kept, 
used  and  changed  in  various  SoSE  activities  shown  in  Figure  11  includes: 


•  systems  information  (outcomes  of  conceptualisation  and  contextualisation,  such  as 
systems  or  SoS  identification  and  specifications  of  interdependencies) 
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•  development  information  (development  requirements,  development  states,  current 
conditions,  targeted  SCOTS  levels)  and  products  (plans,  requirements, 
architectures,  progress  and  documents  for  testing  and  evaluation) 

•  important  data,  information  and  reports  generated  from  analysis  and  assessments 

•  configuration  management  information 

•  activity  coordination  information. 

Engineering  artefacts  are  produced  and  used  always  in  a  certain  context.  It  is  thus 
important  for  complex  systems  development,  such  as  acquisition  projects  or 
capability  programs,  to  ensure  generation,  use,  management  and  traceability  of 
engineering  artefacts  in  right  context.  A  poorly  framed  and  inadequately  defined 
context  could  not  only  have  impact  on  the  efficiency  of  artefacts  generation  but 
also  undermine  quality  and  value  of  work  outcomes  or  even  cause  misuse  of 
artefacts  produced.  Due  to  high  complexity  and  difficulties  in  traceability  and 
manageability,  specific  requirements  for  artefacts  management,  when  facing  a  SoS 
problem  space,  need  to  be  adequately  addressed,  specifically  in  the  following 
aspects: 

•  artefacts  are  related  to  multiple  SoS  and  context-based 

•  artefacts  are  related  to  interrelationships  and  interdependencies  crossing  SoS 

•  artefacts  require  traceability  in  development,  applications  and  management 

•  artefacts  management  is  an  on-going  task  throughout  lifecycles 

•  artefacts  management  should  be  method-based  and  tool-enabled,  rather  than  a 
document-based  practice. 

The  effective  conceptualisation  to  a  SoS  problem  space,  as  suggested  by  SoS  thinking, 
offers  a  sound  foundation  for  managing  context  for  generation,  use  and  management  of 
engineering  artefacts.  Based  on  such  conceptualisation,  a  SoS  thinking-based  approach  to 
SoS  engineering  artefacts  management  has  been  presented  in  [Chen,  2015].  Based  on  the 
engineering  context  schema  shown  in  Figure  15,  this  method  has  a  number  of  desirable 
features  that  are  directly  based  on: 

•  identification  of  SoS  according  to  the  defined  categories 

•  identified  and  captured  interdependencies  and  interrelationships  between  SoS  and 
semantics  associated  with  them 

•  defined  development  states  and  technical  statuses 

•  correspondences  and  associations  between  SoS  and  their  engineering  products  (e.g. 
plans,  architectures,  reports). 

Using  such  a  schema,  stakeholders  or  projects/ programs  can  effectively  conceptualise  and 
contextualise  their  problem  spaces,  communicate  with  other  stakeholders  or  areas,  and 
plan  and  coordinate  development  or  integration  activities.  Integration  needs  (INs)  and 
integration  gaps/ risks,  for  example,  can  be  systematically  identified  and  analysed  in 
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specified  contexts  across  SoS  between  stakeholders,  through  using  Tables  1,  3  and  5,  and 
Figures  4  to  6. 


SoS  Name 

Amphibious  Ship 

SoS  Category 

P_SoS 

Owner/Manage 

r 

Navy 

Architectures/Docs 

®  Links  to  architectures  and  docs. 

Development 

State 

Realised 

Targeted  SCOTS  Level 

SCOTS  Level  2 

Related 

SoS/Sys. 

Name 

SoS 

Category 

Owner/ 

Manager 

Developme 
nt  State 

Interdependenc 
y  Description 

Interdependenc 
y  Engineering 
Status 

Integration 
requirements  / 
Solutions 

Constituent  SoS 

Helicopter  1 

P_SoS 

Navy 

Realised 

Be-deployed-on 

To  be  tested 

@links  to 
integration  req 

Land  vehicle  1 

P_SoS 

Army 

Realised 

Be-transported- 

by 

To  be  tested 

@links  to 
integration  req. 

C4I  systems 

l_SoS 

HQ  + 

Services 

Be-staioned-on 

To  be  integrated 

@links  to 
architectures 

Higher  SoS 

Amph.  Opl 

0_SoS 

HQ 

Planned 

Deployed-to 

To  be  tested 

@links  to 
integration  req. 

Amph.  Op2 

0_SoS 

HQ 

Planned 

Deployed-to 

To  be  analysed 

@links  to 
integration  req. 

Lateral  SoS 

AWD  1 

P_SoS 

Navy 

Planned 

Partner-with 

To  be  analysed 

@links  to 
integration  req. 

Submarine  1 

P_SoS 

Navy 

Planned 

Partner-with 

To  be  analysed 

FFG  1 

P_SoS 

Navy 

Realised 

Partner-with 

To  be  integrated 

@links  to 
integration  req. 

Figure  15  SoS-based  Engineering  context  management 

Apart  from  support  to  individual  SoS  activities,  the  SoS  thinking  approach  can  help  as 
well  the  SoSE  community  in  designing  specific  SoSE  frameworks  for  either  a  given  domain 
or  an  organisation  as  a  whole,  which  will  be  reported  in  a  separate  research  report. 
Through  using  SoS  thinking,  as  mentioned  earlier,  a  number  of  important  integration 
issues  or  difficult  engineering  tasks  for  Defence  can  also  be  addressed  or  conducted 
accordingly,  including: 

•  how  to  adequately  architect  military  SoS  in  different  categories; 

•  how  to  address  main  problems  in  current  defence  architecture  practice  or  in  use  of 
architectural  frameworks; 

•  how  to  systematically  identify  and  specify  integration  needs  (INs)  and  analyse 
potential  integration  gaps  and  risks,  based  on  interdependencies  identified 
between  relevant  SoS; 

•  how  to  achieve  coherent  engineering  context  management  across  projects, 
programs  and  areas,  which  can  effectively  facilitate  communications  and 
collaboration; 

•  how  to  evaluate  and  assess  multiple  aspects  of  military  SoS  in  an  integrated  and 
coordinated  manner  with  adequate  concepts,  methods  and  metrics;  and 
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•  how  to  systematically  manage  joint  force  integration  and  effective  control  and 
manage  changes  and  evolution. 

Some  of  these  issues  or  topics  have  been  reported,  including: 

•  Modelling  and  management  of  relationships  and  interdependencies  between 
military  SoS  [Chen,  2013b] 

•  SoS  engineering  artefacts  management  approach  [Chen,  2015] 

•  Design  and  development  management  of  operation-based  SoS  (or  mission-based 
SoS)  [Chen,  2016], 

•  Concepts,  Methods,  Metrics  and  Processes  for  Assessments  of  Military  Systems-of- 
Sys terns  (to  be  submitted). 

13.  Further  Studies  and  Recommendations 


SoS  thinking  is  complimentary  to  SE  or  SoSE,  rather  than  a  replacement,  and  can  have  a 
broad  impact  to  many  challenging  issues  and  areas  facing  military  SoS.  As  mentioned 
earlier  in  this  report,  there  are  a  number  of  areas  or  topics  where  SoS  thinking  can  be  used 
to  explore  and  address  specific  engineering  issues  and  tasks,  more  importantly  in  a  joint 
fashion  (namely,  using  a  shared  thinking  and  conceptualising  strategy),  which  will  be 
discussed  in  details  in  the  following  areas  or  topics  in  separate  reports  or  papers: 


•  Revisiting  challenges  and  issues  facing  architecture  practice  for  military  SoS 

•  Category-based  design  and  development  management  for  different  military  SoS 

•  Evaluation  and  examination  of  architectures  or  design  products  for  various  SoS,  or 
integrated  capability  development  and  joint  force  integration 

•  Concepts  and  methods  for  military  SoS  assessments 

•  Emergent  behaviours  design  and  implementation  for  military  SoS  (focussing  on 
C2,  joint  fires,  battlefield  awareness,  battlefield  manoeuvre,  and  force  protection) 

•  Force  and  capability  design  management  for  both  products  and  processes 

•  V&V  and  T&E  for  military  SoS  in  different  categories 

•  Integration  management  for  military  SoS. 


Based  on  the  discussions  on  importance  and  potential  benefits  of  applying  SoS  thinking, 
the  following  main  recommendations  are  made  to  Defence: 

•  Key  stakeholders,  including  VCDF,  CASG,  DSTG,  CIOG  and  Services,  should 
jointly  discuss  common  issues  of  military  SoS  and  develop  a  shared  understanding 
on  SoS  engineering  challenges,  through  conducting  some  SoS  case  studies  or 
workshops. 

•  In  order  to  develop  a  good  CoP  for  SoSE  across  key  areas,  Defence  needs  to 
develop  and  provide  clear  and  authoritative  guidance  on  effective  use  of  SoS 
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concepts  as  part  of  relevant  development  and  process  guidance  (such  as 
Integrating  Operational  Concept  Documents  (  IOCD)  and  Capability  Life  Cycle 
manual). 

•  If  SoS  concepts  are  accepted  and  will  be  used  by  Defence,  it  is  suggested  to 
introduce  the  best  practice  or  clear  guidance  in  conceptualisation  to  a  SoS  problem 
space  for  all  activities  and  processes  of  force  and  capability  planning,  design  and 
development.  It  could  include  a  shared  master  list  of  main  or  selected  SoS  in 
different  categories  to  enable  consistent  conceptualisation  and  SoS  lifecycle 
management  for  force  design,  capability  development  and  joint  force  integration 
management. 

•  Defence  should  consider  and  effectively  establish  lifecycle  management  and 
accountability  management  for  military  SoS  in  different  categories. 

•  Through  using  SoS  thinking,  key  stakeholders  should  clearly  consider  and 
effectively  identify  their  focusing  areas  in  design,  development  and  management 
of  military  SoS  in  different  categories,  in  terms  of  their  responsibilities  and 
accountabilities. 

•  If  SoS  thinking  and  SoSE  will  be  considered  and  used  within  Defence,  adequate 
funding  and  resources  should  be  available  in  relevant  areas,  including:  a)  further 
development  of  guidance  and  frameworks  for  adequate  SoSE  practice  for  key 
areas,  processes  or  domains;  b)  the  training  requirements  for  skills  and 
professionalism  in  SoS  thinking  and  SoSE;  c)  improvements  of  some  key  processes 
or  activities;  and  d)  further  development  of  specific  methods,  metrics  and  tools  as 
SoSE  enablers. 


14.  Conclusions 


SoS  thinking  systematically  explores  SoS  concepts  and  critical  engineering  issues  from  a 
number  of  perspectives.  It  can  help  the  community  understand  and  address  complexity  of 
multiple  SoS  in  a  complicated  SoS  problem  space,  and  makes  consistently  conceptualising 
a  SoS  problem  space  with  theory  possible.  It  is  intended  to  offer  a  language  and  an 
approach  for  large  organisations  and  relevant  communities  to  effectively  communicate 
about,  understand  and  deal  with  engineering  challenges  and  issues  of  multiple  SoS.  It 
specifically  provides  insights  on  SoS  diversity  and  identification,  SoS  interdependencies, 
SoS  development  states  and  technical  statuses,  SoS  design,  and  SoS  CoP.  The 
conceptualisation  to  a  SoS  problem  space  through  using  SoS  thinking  can  help  avoid  a 
situation  of  dealing  with  a  messy  collection  of  systems  in  SoS  engineering  and 
management  practice.  It  also  offers  an  effective  contextualisation  mechanism  to  facilitate 
communications  for  SoS  development  activities,  and  control  and  manage  high  complexity 
of  SoS  development  and  management.  SoS  thinking  can  help  defence  stakeholders  to 
effectively  use  SoS  concepts  and  methods  in  force  and  capability  planning  and 
development,  and  work  more  effectively  and  collaboratively  in  joint  force  design  and 
integration,  and  development  of  integrated  capabilities. 
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The  SoS  thinking  perspectives  are  only  briefly  explored  and  discussed  in  this  report,  and 
as  mentioned,  yet  to  be  further  investigated  in  depth  for  more  findings  and  insights  on 
specific  issues  or  topics  of  SoS.  SoS  thinking  is  an  emerging  approach  and  can  be  further 
developed  if  other  important  perspectives  are  identified  and  explored.  Based  on  these 
perspectives  as  a  shared  foundation,  SoSE  researchers  and  practitioners  are  invited  to 
consider  how  to  address  specific  challenges  and  issues  of  military  SoS  in  a  joint  and 
coherent  manner. 
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